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FOREWORD 


The  volume  comprises  extended  abstracts  of  the  papers  selected  for  the  presentation  at  the 
Third  International  Andrei  Ershov  Memorial  Conference  “Perspectives  of  System  Informatics”, 
Akademgorodok  (Novosibirsk,  Russia),  July  6—9,  1999.  The  main  goal  of  the  conference  is  to 
give  an  overview  of  research  directions  which  are  decisive  for  the  growth  of  major  areas  of 
research  activities  in  system  informatics. 

The  conference  is  the  third  one  in  the  line.  The  First  International  Conference  “Perspectives 
of  System  Informatics”  was  held  in  Novosibirsk,  Akademgorodok,  May  27—30,  1991  and  the 
second  in  June  25—28, 1996.  Both  conferences  gathered  a  wide  spectrum  of  specialists  and  were 
undoubtedly  very  successful. 

The  third  conference  includes  many  of  the  subjects  of  the  second  conference,  such  as  the¬ 
oretical  computer  science,  programming  methodology,  new  information  technologies,  and  the 
promising  field  of  artificial  intelligence  —  as  important  components  of  system  informatics.  The 
style  of  the  second  conference  is  preserved  to  a  certain  extent:  a  considerable  number  of  invited 
papers  in  addition  to  contributed  papers.  However,  posters  are  replaced  by  short  talks  mainly 
given  by  young  researchers. 

This  time  73  papers  were  submitted  to  the  conference  by  researchers  from  all  continents. 
Each  paper  was  reviewed  by  three  experts,  at  least  two  of  them  from  the  same  or  closely 
related  discipline  as  the  authors.  The  reviewers  generally  provided  high  quality  assessment  of 
the  papers  and  often  gave  extensive  comments  to  the  authors  for  the  possible  improvement 
of  the  presentation.  As  a  result,  the  programme  committee  selected  27  high  quality  papers  as 
regular  talks  and  17  papers  as  short  talks.  A  broad  range  of  “hot”  topics  in  system  informatics  are 
covered  by  eight  invited  talks  given  by  prominent  computer  scientists  from  different  countries. 

The  conference,  like  the  previous  ones,  is  dedicated  to  the  memory  of  A.  P.  Ershov,  the  real 
and  recognized  leader  in  Soviet  (and  Russian)  informatics. 

The  late  Academician  Andrei  P.  Ershov  was  a  man  for  all  seasons.  He  commanded  universal 
respect  and  received  affection  all  over  the  world.  His  view  of  programming  was  both  a  human 
one  and  a  scientific  one.  He  created,  at  Akademogorodok,  a  unique  group  of  scientists  —  some 
now  in  far  away  regions  of  the  world:  a  good  example  of  “technology  transfer”,  although  perhaps 
not  one  that  too  many  people  in  Russia  are  happy  about. 

Many  of  his  disciples  and  colleagues  continue  to  work  in  the  directions  initiated  or  stimulated 
by  him,  at  the  A.  P.  Ershov  Institute  of  Informatics  Systems.  The  institute  was'and  is  the  main 
organizer  of  the  three  conferences. 

We  are  glad  to  express  our  gratitude  to  all  the  persons  and  organizations  who  contributed 
to  the  conference  —  to  the  sponsors  for  their  moral,  financial  and  organizational  support,  and 
to  the  members  of  local  Organizing  Committee  for  their  mutual  efforts  towards  a  success  of 
this  event.  We  are  especially  grateful  to  N.  Cheremnykh  for  her  selfless  labour  when  preparing 
the  conference. 


July,  1999  D.  Bjprner, 

M.  Broy, 
A.  Zamulin 
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Algebraic  Specifications 


The  Common  Framework  Initiative  for  Algebraic  Specification 

and  Development  of  Software* 

Donald  Sannella 

Laboratory  for  Foundations  of  Computer  Science 
University  of  Edinburgh,  UK 

dtsOdcs .ed.ac.uk  www . dcs . ed . ac .uk/*dts/ 


Abstract.  The  Common  Framework  Initiative  (CoFI)  is  an  open  international  collaboration  which  aims 
to  provide  a  common  framework  for  algebraic  specification  and  development  of  softwEire.  The  central 
element  of  the  Common  Framework  is  a  specification  language  called  Casl  for  formal  specification  of 
functional  requirements  and  modular  software  design  which  subsumes  many  previous  cdgebraic  specification 
languages.  This  paper  is  a  brief  summary  of  past  and  present  work  on  CoFI. 

1  Introduction 

Algebraic  specification  is  one  of  the  most  extensively-developed  approaches  in  the  formal  methods  area.  The 
most  fundamental  assumption  underlying  algebraic  specification  is  that  programs  are  modelled  as  many-sorted 
algebras  consisting  of  a  collection  of  sets  of  data  values  together  with  functions  over  those  sets.  This  level  of 
abstraction  is  commensurate  with  the  view  that  the  correctness  of  the  input/output  behaviour  of  a  program 
takes  precedence  over  all  its  other  properties.  Another  common  element  is  that  specifications  of  programs 
consist  mainly  of  logical  axioms,  usually  in  a  logical  system  in  which  equality  has  a  prominent  role,  describing 
the  properties  tha.t  the  functions  are  required  to  satisfy.  This  property-oriented  approach  is  in  contrast  to 
so-called  model- oriented  specifications  in  frameworks  like  VDM  which  consist  of  a  simple  realization  of  the 
required  behaviour.  Confusingly  —  because  the  theoretical  basis  of  algebraic  specification  is  largely  in  terms  of 
constructions  on  algebraic  models  —  it  is  at  the  same  time  much  more  model-oriented  than  approaches  such 
as  those  based  on  type  theory  (see  e.g.  [NPS90]),  where  the  emphasis  is  almost  entirely  on  syntax  and  formal 
systems  of  rules  and  semantic  models  are  absent  or  regarded  as  of  secondary  importance. 

The  past  25  years  has  seen  a  great  deal  of  research  on  the  theory  and  practice  of  algebraic  specification. 
Overviews  of  this  material  include  [Wir90],  [BKLOS91],  [LEW96],  [ST97],  [AKK99]  and  [ST??].  Developments 
on  the  foundational  side  have  been  balanced  by  work  on  applications,  but  despite  a  number  of  success  stories, 
industrial  adoption  has  so  far  been  limited.  The  proliferation  of  algebraic  specification  languages  is  seen  as 
a  significant  obstacle  to  the  dissemination  and  use  of  these  techniques.  Despite  extensive  past  collaboration 
between  the  main  research  groups  involved  and  a  high  degree  of  agreement  concerning  the  basic  concepts,  the 
field  has  given  the  appearance  of  being  extremely  fragmented,  with  no  de  facto  standard  specification  language, 
let  alone  an  international  standard.  Moreover,  although  many  tools  supporting  the  use  of  algebraic  techniques 
have  been  developed  in  the  academic  community,  none  of  them  has  gained  wide  acceptance,  at  least  partly 
because  of  their  isolated  usability:  each  tool  uses  a  different  specification  language. 

Since  late  1995,  work  has  been  underway  in  an  attempt  to  remedy  this  situation.  The  Common  Framework 
Initiative  (abbreviated  CoFI)  is  an  open  international  collaboration  which  aims  to  provide  a  common  framework 

*  This  research  w^as  supported  by  the  ESPRIT-funded  CoFI  Working  Group. 
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for  algebraic  specification  and  development  of  software.  The  Common  Framework  is  intended  to  be  attractive  to 
researchers  in  the  field  as  a  common  basis  for  their  work,  and  to  ultimately  become  attractive  for  use  in  industry. 
The  central  element  of  the  Common  Framework  is  a  specification  language  called  Casl  (the  Common  Algebraic 
Specification  Language),  intended  for  formal  specification  of  functional  requirements  and  modular  software 
design  and  subsuming  many  previous  specification  languages.  Development  of  prototyping  and  verification  tools 
for  Casl  will  lead  to  them  being  interoperable,  i.e.  capable  of  being  used  in  combination  rather  than  in  isolation. 

Most  effort  to  date  has  concentrated  on  the  design  of  Casl,  which  concluded  in  late  1998.  Even  though  the 
intention  was  to  base  the  design  on  a  critical  selection  of  concepts  and  constructs  from  existing  specification 
languages,  it  was  not  easy  to  reach  a  consensus  on  a  coherent  language  design.  A  great  deal  of  careful  con¬ 
sideration  was  given  to  the  effect  that  the  constructs  available  in  the  language  would  have  on  such  aspects  as 
the  methodology  for  formal  development  of  modular  software  from  specifications  and  the  ease  of  constructing 
appropriate  support  tools.  A  complete  formal  semantics  for  Casl  was  produced  in  parallel  with  the  later  stages 
of  the  language  design,  and  the  desire  for  a  relatively  straightforward  semantics  was  one  factor  in  the  choice 
between  various  alternatives  in  the  design.  Work  on  CoFI  has  been  an  activity  of  Ifip  WG  1.3  and  the  design 
of  Casl  has  been  approved  by  this  group. 

This  paper  is  a  brief  summary  of  work  in  CoFI  with  pointers  to  information  available  elsewhere.  Casl  is 
given  special  prominence  since  it  is  the  main  concrete  product  of  CoFI  so  far.  A  more  extensive  description  of 
the  rationale  behind  CoFI  and  Casl  may  be  found  in  [Mos97]  and  [Mos99]. 

2  CASL 

Casl  represents  a  consolidation  of  past  work  on  the  design  of  algebraic  specification  languages.  With  a  few 
minor  exceptions,  all  its  features  are  present  in  some  form  in  other  languages  but  there  is  no  language  that 
comes  close  to  subsuming  it.  Designing  a  language  with  this  particular  novel  collection  of  features  required 
solutions  to  a  number  of  subtle  problems  in  the  interaction  between  features. 

It  soon  became  clear  that  no  single  language  could  suit  all  purposes.  On  one  hand,  sophisticated  features 
are  required  to  deal  with  specific  programming  paradigms  and  special  applications.  On  the  other,  important 
methods  for  prototyping  and  reasoning  about  specifications  only  work  in  the  absence  of  certain  features:  for 
instance,  term  rewriting  requires  specifications  with  equational  or  conditional  equational  axioms. 

Casl  is  therefore  the  heart  oi  a  family  of  languages.  Some  tools  will  make  use  of  well-delineated  sub-languages 
of  Casl  obtained  by  syntactic  or  semantic  restrictions,  while  extensions  of  Casl  will  be  defined  to  support 
various  paradigms  and  applications.  The  design  of  Casl  took  account  of  some  of  the  planned  extensions, 
particularly  one  that  involves  higher-order  functions  [MHK98],  and  this  had  an  important  impact  on  decisions 
concerning  matters  like  concrete  syntax. 

Casl  consists  of  the  following  major  parts  or  “layers” :  basic  specifications;  structured  specifications;  archi¬ 
tectural  specifications;  specification  libraries.  A  detailed  description  of  the  features  of  Casl  may  be  found  in 
[Mos99]  and  the  complete  language  definition  is  in  [CoFI98].  Here  we  just  give  a  quick  overview  and  a  couple  of 
simple  examples  in  the  hope  that  this  will  give  a  feeling  for  what  Casl  is  like.  Further  examples  may  be  found 
in  the  appendices  of  [CoFI98].  Since  features  of  various  existing  specification  languages  have  found  their  way 
into  Casl  in  some  form,  there  are  of  course  many  interesting  relationships  with  other  languages.  It  is  not  the 
purpose  of  this  paper  to  detail  these  so  many  relevant  references  are  omitted. 

A  Casl  basic  specification  denotes  a  class  of  many-sorted  partial  first-order  structures:  algebras  where  the 
functions  are  partial  or  total,  and  where  also  predicates  are  allowed.  These  are  classified  by  signatures,  which  list 
sort  names,  partial  and  total  function  names,  and  predicate  names,  together  with  profiles  of  functions  and  pred¬ 
icates.  The  sorts  are  partially  ordered  by  a  subsort  inclusion  relation,  which  is  interpreted  as  embedding  rather 
than  set-theoretic  inclusion,  and  is  required  to  commute  with  overloaded  functions.  A  Casl  basic  specification 
includes  declarations  to  introduce  components  of  signatures  and  axioms  to  give  properties  of  structures  that  are 
to  be  considered  as  models  of  a  specification.  Axioms  are  written  in  first-order  logic  (so,  with  quantifiers  and  the 
usual  logical  connectives)  built  over  atomic  formulae  which  include  strong  and  existential  equalities,  definedness 
formulae  and  predicate  applications,  with  generation  constraints  added  as  special,  non-first-order  sentences. 
The  interpretation  of  formulae  is  as  in  classical  two- valued  first-order  logic,  in  contrast  to  some  frameworks  that 
accommodate  partial  functions.  Concise  syntax  is  provided  for  specifications  of  “datatypes”  with  constructor 
and  selector  functions. 

Here  is  an  example  of  a  basic  specification: 

free  types  Nat  0  \  sort  Pos\ 

Pos  ::=  suc{pre  :  Nat) 
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op  pre  :  Nat  ->?  Nat 

axioms 

-idef  pre{0)\ 

Vn  ;  Nat  •  pre{suc{n))  =  n 

pred  even—  :  Nat 

var  n  :  Nat 

•  even  0 

•  even  suc{n)  -^even  n 

The  remaining  features  of  Casl  do  not  depend  on  the  details  of  the  features  for  basic  specifications,  so 
this  part  of  the  design  is  orthogonal  to  the  rest.  An  important  consequence  of  this  is  that  sub-languages  and 
extensions  of  Casl  can  be  defined  by  restricting  or  extending  the  language  of  basic  specifications  (under  certain 
conditions)  without  the  need  to  reconsider  or  change  the  rest  of  the  language. 

Casl  provides  ways  of  building  complex  specifications  out  of  simpler  ones  (the  simplest  ones  being  basic 
specifications)  by  means  of  various  specification-building  operations.  These  include  translation,  hiding,  union, 
and  both  free  and  loose  forms  of  extension.  A  structured  specification  denotes  a  class  of  many-sorted  partial 
first-order  structures,  as  with  basic  specifications.  Thus  the  structure  of  a  specification  is  not  reflected  in  its 
models:  it  is  used  only  to  present  the  specification  in  a  modular  style.  Structured  specifications  may  be  named 
and  a  named  specification  may  be  generic,  meaning  that  it  declares  some  parameters  that  need  to  be  instantiated 
when  it  is  used.  Instantiation  is  a  matter  of  providing  an  appropriate  argument  specification  together  with  a 
fitting  morphism  firom  the  parameter  to  the  argument  specification.  Fitting  may  also  be  accomplished  by  the  use 
of  named  views  between  specifications.  Generic  specifications  correspond  to  what  is  known  in  other  specification 
languages  as  {pushout-style)  parametrized  specifications. 

Here  is  an  example  of  a  generic  specification  (referencing  a  specification  named  Partial_Order,  which  is 
assumed  to  declare  the  sort  Elem  and  the  predicate  —  <  _.); 

spec  List_with_Order  [Partial-Order]  = 

free  type  List[Elem]  ::=  nil  \  cons{hd  :?Elem',tl :? List[Elem]) 

then 

local 

op  insert :  Elem  x  List[Elem]  List[Elem]-, 
vars  X,  y  :  Elem]  I  :  List[Elem] 
axioms  insert{x,  nil)  =  cons {x,  nil)] 

X  <  y  ^  insert{x,  cons{y,  1))  =  cons{x,  insert{y,  1))] 

■^(®  <  ?/)  ^  insert {x,  cons {y,l))  =  cons{y,insert{x,l)) 

within 

pred  order [—  <  __]  :  List[Elem]  x  List[Elem] 
vars  X  :  Elem]  I  :  List[Elem] 
axioms  order[.-  <  __](n27)  =  nil] 

order[—  <  —]{cons{x,  1))  =  insert{x,  order[..  <  — ](i)) 

end 

Architectural  specifications  in  Casl  are  for  describing  the  modular  structure  of  software,  in  constrast  to 
structured  specifications  where  the  structure  is  only  for  presentation  purposes.  Architectural  specifications  are 
probably  the  most  novel  aspect  of  Casl;  they  are  not  entirely  new,  but  they  have  no  counterpart  in  most 
algebraic  specification  languages.  An  architectural  specification  consists  of  a  list  of  unit  declarations,  indicating 
the  component  modules  required  with  specifications  for  each  of  them,  together  with  a  unit  term  that  describes 
the  way  in  which  these  modules  are  to  be  combined.  (There  is  an  unfortunate  potential  for  confusion  here:  in 
Casl,  the  term  “architecture”  refers  to  the  “implementation”  modular  structure  of  the  system  rather  than  to 
the  “interaction”  relationships  between  modules  in  the  sense  of  [AG97].)  Units  are  normally  functions  which 
map  structures  to  structures,  where  the  specification  of  the  unit  specifies  properties  that  the  argument  structure 
is  required  to  satisfy  as  well  as  properties  that  are  guaranteed  of  the  result.  These  functions  are  required  to  be 
persistent,  meaning  that  the  argument  structure  is  preserved  intact  in  the  result  structure.  This  corresponds  to 
the  fact  that  a  software  module  must  use  its  imports  as  supplied  without  altering  them. 

Here  is  a  simple  example  of  an  architectural  specification  (referencing  ordinary  specifications  named  List, 
Char,  and  Nat,  assumed  to  declare  the  sorts  Elem  and  List[Elem],  Char,  and  Nat,  respectively): 
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arch  spec  CNXiST  = 
units 

C  :  Char ; 

N  :  Nat  ; 

F  :  ELEM  ->■  LiST[ElEM] 

result  F[C  fit  Elem  ^  Char]  and  F[N  fit  Elem  H-  Nat] 


More  about  architectural  specifications,  including  further  examples,  may  be  found  in  [BST99]. 

Libraries  in  Casl  are  collections  of  named  specifications.  A  specification  can  refer  to  an  item  in  a  library  by 
^vmg  Its  name  and  the  location  of  the  library  that  contains  it.  Casl  includes  direct  support  for  establishing 
distributed  libraries  on  the  Internet  with  version  control. 


3  Semantics 

The  formal  semantics  of  Casl,  which  is  complete  but  whose  presentation  still  requires  some  work,  is  in  [CoFI99]. 
The  semantics  is  divided  into  the  same  parts  as  the  language  definition  (basic  specifications,  structured  specifi¬ 
cations,  etc.)  but  in  each  part  there  is  also  a  split  into  static  semantics  and  model  semantics. 

The  static  semantics  checks  well-formedness  of  phrases  and  produces  a  “syntactic”  object  as  result,  failing 
to  produce  any  result  for  ill-formed  phrases.  For  example,  for  a  basic  specification  the  static  semantics  yields 
a,  theory  presentation  containing  the  sorts,  function  symbols,  predicate  symbols  and  axioms  that  belong  to 
the  specification.  (Actually  it  yields  an  enrichment:  when  a  basic  specification  is  used  to  extend  an  existing 
specification  it  may  refer  to  existing  sorts,  functions  and  predicates.)  A  phrase  may  be  ill-formed  because  it 
makes  reference  to  non-existent  identifiers  or  because  it  contains  a  sub-phrase  that  fails  to  type  check.  The  model 
semantics  provides  the  corresponding  model-theoretic  part  of  the  semantics,  and  is  intended  to  be  applied  only 
to  phrases  that  are  well-formed  according  to  the  static  semantics.  For  a  basic  specification,  the  model  semantics 
yields  a  cl^s  of  models.  A  statkally  well-formed  phrase  may  still  be  ill-formed  according  to  the  model  semantics: 
for  example,  if  a  generic  specification  is  instantiated  with  an  argument  specification  that  has  an  appropriate 
signature  but  which  has  models  that  fail  to  satisfy  the  axioms  in  the  parameter  specification,  then  the  result  is 
undefined.  The  judgements  of  the  static  and  model  semantics  are  defined  inductively  by  means  of  rules  in  the 
style  of  Natural  Semantics. 

The  orthogonality  of  basic  specifications  in  Casl  with  respect  to  the  rest  of  the  language  is  reflected  in 

^  institution  [GB92]  called  an  institution  with  symbols 

[Mos98j.  (For  readers  who  are  unfamiliar  with  the  notion  of  institution,  it  corresponds  roughly  to  “logical 
system  appropriate  for  writing  specifications”.)  The  semantics  of  basic  specifications  is  regarded  as  defining 

a  pmticular  institution  with  symbols,  and  the  rest  of  the  semantics  is  based  on  an  arbitrary  institution  with 
symbols. 

The  semantics  provides  a  basis  for  the  development  of  a  proof  system  for  Casl.  As  usual,  at  least  three  levels 
are  needed:  proving  consequences  of  sets  of  axioms;  proving  consequences  of  structured  specifications;  and  finally 
proving  the  refinement  relation  between  structured  specifications.  The  semantics  of  Casl  gives  a  reference  point 
for  checking  the  soundness  of  each  of  the  proposed  proof  systems  and  for  studying  their  completeness. 

4  Methodology 

The  original  motivation  for  work  on  algebraic  specification  was  to  enable  the  stepwise  development  of  correct 
software  systems  from  specifications  with  verified  refinement  steps.  Casl  provides  good  support  for  the  pro¬ 
duction  of  specifications  both  of  the  problem  to  be  solved  and  of  components  of  the  solution,  but  it  does  not 
incorporate  a  specific  notion  of  refinement.  Architectural  specifications  go  some  way  towards  relating  differ¬ 
ent  stages  of  development  but  they  do  not  provide  the  full  answer.  Other  methodological  issues  concern  the 
endpoints  of  the  software  development  process:  how  the  original  specification  is  obtained  in  the  first  place 
(r^uirements  engineering),  and  how  the  transition  is  made  from  Casl  to  a  given  programming  language  Fi¬ 
nally,  the  usual  issues  in  programming  methodology  are  relevant  here,  for  instance:  verification  versus  testing- 
software  reuse  and  specification  reuse;  software  reverse  engineering;  software  evolution. 

Casl  has  been  designed  to  accommodate  multiple  methodologies.  Various  existing  methodologies  and  styles 
of  use  of  algebraic  specifications  have  been  considered  during  the  design  of  Casl  to  avoid  unnecessary  difficulties 
for  users  who  are  accustomed  to  a  certain  way  of  doing  things.  For  the  sake  of  concreteness,  the  present  author 
prefers  the  methodology  espoused  in  [ST97],  and  work  on  adapting  this  methodology  to  Casl  has  begun. 
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5  Support  tools 

Tool  activity  initially  focussed  on  the  concrete  syntax  of  Casl  to  provide  feedback  to  the  language  design 
since  the  exact  details  of  the  concrete  syntax  can  have  major  repercussions  for  parsing.  Casl  offers  a  flexible 
syntax  with  mixfix  notation  for  application  of  functions  and  predicates  to  arguments,  which  requires  relatively 
advanced  parsing  methods.  ASF+SDF  was  used  to  prototype  the  Casl  syntax  in  the  course  of  its  design, 
and  several  other  parsers  have  been  developed  concurrently.  Also  available  is  a  package  for  uniform 

formatting  of  CASL  specifications  with  easy  conversion  to  HTML  format.  ATerms  [BK098]  have  been  chosen 
as  the  common  interchange  format  for  CoFI  tools.  This  provides  a  tree  representation  for  various  objects 
(programs,  specifications,  abstract  syntax  trees,  proofs)  and  annotations  to  store  computed  results  so  that  one 
tool  can  conveniently  pass  information  to  another.  Work  is  underway  on  a  format  for  annotations  and  on  a  list 
of  specific  kinds  of  annotations. 

At  present,  the  principal  focus  of  tools  work  in  CoFI  is  on  adapting  tools  that  already  exist  for  use  with  Casl. 
Existing  rewrite  engines  such  as  in  OBJ,  ASF+SDF  and  ELAN  should  provide  a  good  basis  for  prototyping 
(parts  of)  Casl  specifications.  For  verification  tools,  we  plan  to  reuse  existing  proof  tools  for  specific  subsets 
of  Casl:  equational,  conditional,  full  first-order  logic  with  total  functions,  total  functions  with  subsorts,  partial 
functions,  etc.  The  integration  of  proof  tools  such  as  SPIKE,  EXPANDER  and  others  will  provide  the  potential  to 
perform  proofs  by  induction,  observational  proofs,  termination  proofs,  etc.  One  system  on  which  development  is 
already  well-advanced  is  HOL-CASL  [MKK98]  which  provides  static  analysis  of  Casl  specifications  and  theorem 
proving  via  an  encoding  into  the  Isabelle/HOL  theorem  prover  [Pau94].  Another  is  INKA  5.0  [AHMS99]  which 
provides  theorem  proving  for  a  sub-language  of  Casl  that  excludes  partial  functions. 


6  Specification  of  reactive  systems 

An  area  of  particular  interest  for  applications  is  that  of  reactive,  concurrent,  distributed  and  real-time  systems. 
There  is  considerable  past  work  in  algebraic  specification  that  tackles  systems  of  this  kind,  but  nonetheless 
the  application  of  Casl  to  such  systems  in  speculative  and  preliminary  in  comparison  with  the  rest  of  CoFI. 
The  aim  here  is  to  propose  and  develop  one  or  more  extensions  of  CASL  to  deal  with  systems  of  this  kind, 
and  to  study  methods  for  developing  software  from  such  specifications.  Extensions  in  three  main  categories  are 
currently  being  considered: 

-  Combination  of  formalisms  for  concurrency  (e.g.  CCS,  Petri  nets,  GSP)  with  Casl  for  handling  classical 
(static)  data  structures; 

-  Formalisms  built  over  Casl,  where  processes  are  treated  as  special  dynamic  data;  and 

-  Approaches  where  CASL  is  used  for  coding  at  the  meta-level  some  formalism  for  concurrency,  as  an  aid  to 
reasoning. 

Work  in  this  area  begun  only  after  the  design  of  Casl  was  complete  and  so  it  is  still  in  its  early  stages. 


7  Invitation 


CoFI  is  an  open  collaboration,  and  new  participants  are  welcome  to  join  at  any  time.  Anybody  who  wishes 
to  contribute  is  warmly  invited  to  visit  the  CoFI  web  site  at  http://www.brics.dk/Projects/CoFI/  where 
all  CoFI  documentation,  design  notes,  minutes  of  past  meetings  etc.  are  freely  available.  Announcements  of 
general  interest  to  CoFI  participants  are  broadcast  on  the  low-volume  mailing  list  cofi-list@brics.dk  and 
each  task  group  has  its  own  mailing  list;  see  the  CoFI  web  site  for  subscription  instructions.  All  of  these  mailing 
lists  are  moderated.  Funding  from  the  European  Commission  is  available  until  September  2000  to  cover  travel 
to  CoFI  meetings  although  there  are  strict  rules  concerning  eligibility,  see  http://www.dcs.ed.ac.uk/hoine/ 
dts/CoFI-WG/. 
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sv^ems  Bvl  h  ^  investigation  is  behaviour  of  the  continuous  components  of  hybrid 

A  firsTorder  f  "^  7  7  ""7  interacting  at  discrete  times. 

first-order  logical  formdization  of  hybrid  systems  is  proposed  in  which  the  trajectories  of  the  continuous 
components  are  presented  by  majorant-computable  functionals. 


1  Introduction 

t  htbrwTvsl*™"’  the  problems  of  exact  mathematical  formalization  of  complex  systems  such 

toerac  ^  "^twork  of  digital  and  anLg  devices 

interacting  at  discrete  times.  An  important  characteristic  of  hybrid  systems  is  that  they  incorporate  both 

actuators  controlled  by  programs.  These  programs  are  designed  to  select,  control,  and  supervise  the  behaviours 

taSmrSave°areT‘f°°'"‘“'  "™*‘i6ation  of  behaviours  of  hybrid  systems  have  recentiy 

become  active  area^  of  research  in  computer  science  (for  example  see  [7, 10, 11, 15, 16, 191).  We  use  the  models 
of  hybrid  systems  proposed  by  Nerode,  Kohn  in  [19].  i  -  .  >  .  ,  j;  we  use  tne  moaeis 

contobedfvTlr  “  continuous  piant  that  is  disturbed  by  mrternai  worid  and 

smsOT  tultfon  rfTtTnfT  T.  automaton.  The  control  program  reads  sensor  data,  a 

Tn  the  Dimu  The  n  1  ll  ”  “  ““<*•  computes  the  next  control  law.  and  imposes  it 

on  the  plant.  The  plant  will  continue  using  this  control  law  until  the  next  such  intervention. 

A  representation  of  external  world  is  an  input  data  of  the  plant.  The  control  automaton  has  input  data  (the 

by  thrrumT,s'”TbrfiT‘ n  automaton  is  modelled 

contrraZmaMn  “"1  “  “I  “Tf  ™asurement  into  Input  symbols  of  the  intemal 

and  oloTlhaLT  Tb  H  .  automaton  with  finite  input 

nd  output  alphabets.  The  second  unit  is  the  internal  control  automaton,  which  has  a  symbolic  representation 

pLnt  rouTZt  The  "ird  f  “  “  “’■“‘’“li'  of  the  next  control  law  to  be  imposed  on  the 

fnto  th^  art  ml  C  ,  n  “  1  convmer  which  converts  these  output  symbols  representing  control  laws 

autolata  at  Hmir/  IT  T?  Plat-t  The  plant  interacts  with  the  external  world  and  the  control 

automata  at  times  t,,  where  the  time  sequence  {(,}  satisfies  realizability  requirements 

trai™  orTe^  of  investigation  is  behaviour  of  the  continuous  compouents.  In  [W] ,  the  set  of  all  possible 

trajectories  of  the  plant  was  called  as  a  performance  specification.  We  propose  a  first-order  logical  formalization 
of  hybrid  systems  in  which  the  trajectories  of  the  continuous  components  (the  performance  specification)  are 

1.  An  information  about  the  external  world  is  represented  by  a  majorant-computable  real- valued  function  In 
nontrivial  cases  for  proper  behaviour  our  system  should  analyse  some  complicated  external  information  at  every 
moment  when  such  information  can  be  processed.  In  general  case,  we  can’t  represent  this  information  by  several 

Str^^fn^rmluo^sho^^^  behaviours  of  the  external  world  may  be  unknown  in  advance.  Note  that  an 
should  be  measured  so,  in  some  sense,  it  is  computable.  According  this  reasons  we  present 
to  external  information  by  a  majorant-computable  real-valued  function.  ^ 

2.  The  plant  is  given  by  a  real-valued  functional.  At  the  moment  of  interaction,  using  the  law  computed  bv  the 
discrete  device,  the  plant  transforms  external  function  to  a  real  value  which  is  the  oStput  to  ^1^  So  Z 

r  -thematoal  tool  to  a  tomalLtto  S  th"ohS 

reprerntaUon  o?Znl.  .  as  a  basic  one,  this  formalization  is  compatible  with 

epresentation  of  the  plant  by  an  ordinary  differential  equation  (see  [13, 20]).  Really,  if  there  exists  some  method 
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for  approximate  computing  of  the  solution  to  the  differential  equation  that  is  based  on  difference  operators  like 
the  Galerkin  method,  then  such  solution  can  be  described  by  a  computable  functional  (see  [13,20]). 

3.  The  trajectories  of  plants  are  described  by  computable  functionals.  So  the  trajectories  are  exactly  characterized 
in  logical  terms  (via  T-formulas).  Thus,  the  proposition  is  proved  which  connects  the  trajectory  of  a  plant  with 
validity  of  two  Z'-formulas  in  the  basic  model. 


2  Basic  Notions 


To  construct  a  formalization  of  hybrid  systems  we  introduce  a  basic  model  and  recall  the  notions  of  majorant- 
computability  of  real-valued  functions  and  functionals.  To  specify  complicated  systems  such  as  hybrid  systems 
we  extend  the  real  numbers  IR  by  adding  the  list  superstructure  T(]R),  the  set  of  finite  sequences  (words).  A*, 
of  elements  of  A,  where  A  is  a  finite  alphabet,  together  with  the  predicates  Fa,  for  each  elements  Oj  of  A,  and 
appropriate  operations  for  working  with  elements  of  L(IEl)  and  A*. 

We  consider  the  many-sorted  model  M  =<  HW(IR),  A*  >  with  the  following  sorts: 

1.  HW(]R)  =  (H;  L(]R),  cons,  e <,[]),  where 

IR  =<  IR,  0, 1,  +,  •,  <>  is  the  standard  model  of  the  reals,  denoted  also  by  IR; 
the  set  L(]R)  is  constructed  by  induction: 

(a)  io(lR')  =  IR; 

(b)  Ti+i=the  set  of  finite  ordered  sequences  (lists)  of  elements  of  IR  U  L,  (IR): 

{c)L{jR)  =  \j  um. 

(d)  O-HW(IR)  =  {0, 1,  +  ,-,<}  U  {cons,  e,  Q},  where  cons,e,  0  (empty  list)  are  defined  in  standard  way  (  see 

[8])-  . 

At  first  this  structure  was  proposed  by  Backus  in  [1],  now,  it  is  rather  well  studied  in  [2, 5, 8].  This  structure 
enables  us  to  define  the  natural  numbers,  to  code,  and  to  store  information  via  formulas. 

2.  A*  =<  A*,  (7  A*  >  is  the  set  of  finite  sequences  (words)  of  elements  of  A,  where  A  =  (aj, . . .  ,a„}  is  a  finite 

alphabet.  The  elements  of  the  language  a  a*  —  {Pai  ,■  ■■,  Pa„ ,  =,  €,  cone,  ()}  are  defined  in  standard  way  (see 
[23]).  ,  ^ 

3.  <tm  =  'rHvv(iR)  U  (7^.  U  {*},  where  *  are  defined  in  the  following  way; 

(a)  *  ;  A*  X  HW(]R) HW(]R), 

(b)  (flii,-- .,«ifc)  *  [a^i,  ,a;„]  =  [yi,. .  .,?/^],  where  m  =  min(fy,n)  and 

y  •  =  /  ^  ~  ) 

^  (0  otherwise  . 


The  variables  of  ctm  subject  to  the  following  conventions:  a,  b,  c,d, . . .  range  over  IR,  li,  la,  •  -  •  range  over  T(]R), 
x,y,z,...  range  over  IRU  i(lR),  m , . . .  On  range  over  A,  a,  range  over  A*.  This  notation  gives  us  easy 

way  to  assert  that  something  holds  of  real  numbers,  of  lists,  or  of  words. 

The  notions  of  a  term  and  an  atomic  formula  in  the  languages  anwriR.)  and  are  given  in  a  standard 
manner. 

The  set  of  atomic  formulas  in  ctm  is  the  union  of  the  sets  of  atomic  formulas  in  ohw(ir),  a  a*,  and  the  set 
of  formulas  of  the  type  ■w*li  =  Ij.  The  set  of  Aq -formulas  in  um  is  the  closure  of  the  set  of  atomic  formulas 
in  um  under  A,V, -i,  3a;  €  l,\/x  £  l,3a  £  w  and  Va  £  w.  The  set  of  B-formulas  in  aM  is  the  closure  of 
the  set  of  Ao-formulas  under  A,  V,3a;  £  l,\lx  £  1, 3a  £  w,'^a  £  w,  and  3.  We  define  H -formulas  as  negations 
of  i7-formulas. 

We  use  definability  as  one  of  the  basic  conceptions.  Montague  [17]  proposed  to  consider  computability  from 
the  point  of  view  of  definability.  Later,  many  authors  among  them  Ershov  [5],  Moschovakis  [18]  paid  attention 
to  properties  of  this  approach  applied  to  various  basic  models. 


Definition  1.  1  A  set  B  C  HW(IR)  x  (A*)"  is  S-definable  if  there  exists  a  E-formula  $(x)  such  that 
x£B  ${x).  2.  A  function  f  is  S -definable  if  its  graph  is  E -definable 

In  a  simiW  way,  we  define  the  notions  of  11 -definable  functions  and  sets.  The  class  of  A-definable  functions 
[sets)  IS  the  intersection  of  the  class  T-defiiiable  functions  (sets)  and  the  class  of  i7-definable  functions  (sets) 
Properties  of  E-,  2T-,  A-  definable  sets  and  functions  were  investigated  in  [5,8, 12].  Note  only  that  A-definable 
sets  are  analogies  of  recursive  sets  on  the  natural  numbers. 


We  will  use  majorant-computable  functions  and  functionals  to  formalize  information  about  external  world 
and  plants.  Let  us  recall  the  notion  of  computability  for  real-valued  functions  and  functional  proposed  and 
investigated  m  [12, 13].  A  real-valued  function  (functionals)  is  said  to  be  majorant-computable  if  we  can  construct 
a  special  kind  of  nonterminating  process  computing  approximations  closer  and  closer  to  the  result. 
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Definition  2.  A  function  f  :  IR"  IR  is  called  majorant-computable  if  there  exist  an  effective  sequence  of  S- 
formulas  {^s(x,y)}sGa;  and  an  effective  sequence  of  IT -formulas  {Gs{'x.,y)}seio  such  that  the  following  conditions 
hold. 

1.  For  all  s  €  OJ,  X  €  IR",  the  formulas  and  Gs  define  the  same  nonempty  interval  <  (Xs^Ps  >■ 

2.  For  all  x  €  IR”,  the  sequence  {<  aa,Ps  >}«€«  decreases  monotonically,  i.e.,  <  as+i,^s+i  >C<  > 

for  s  e  w; 

3.  For  all  x  G  dom(/),  /(x)  =2/0  flse^  <  OLs,Pe  >=  {y}  holds. 

For  formalization  of  information  about  external  world  we  will  use  the  following  set.  JF  —  {/|/  is  a  majorant- 
computable  total  real- valued  function}. 

An  important  property  of  a  total  real- valued  function,  which  will  be  used  below,  is  that  the  function  is  majorant- 
computable  if  and  only  if  its  epigraph  and  ordinate  set  are  i7-definable  (i.e.  effective  sets). 

Definition  3.  Let  gi  be  Godel  numbering  of  a  set  Ai,  p2  be  Godel  numbering  of  a  set  A2.  A  procedure  h  : 
Ai  A2  is  said  to  be  effective  procedure  if  there  exists  recursive  function  ^  such  that  the  following  diagram  is 
commutative 

.  N-^N 
Pi  4-  p2  4- 
Ai  A  A2  . 

Denote  the  set  of  i7-formulas  by  S  and  the  set  of  77-formulas  n. 

Definition  4.  A  set  R  C  IR”"*"^  x  F  is  said  to  be  S -definable  by  an  effective  procedure  ^  :  S  x  S  ->  S  if  for 
each  majorant-computable  function  f  and  for  S -formulas  A{x,y),  B{x,y)  with  the  following  eonditions: 
f{x)  =  2/ A(x,  ■)  <y  <  B(x,  •)  and  {z  |  A(x,  z)}  U  (z  |  B(x,  z)}  =  ]R\{y} 
the  following  proposition  holds  M  }=  R{x,y,f)  o  M  |=  <p(A,B)(x,y). 

In  a  similar  way,  we  define  the  notion  of  11 -definable  functional  by  an  effective  procedure  1/)  :  S  x  S  11. 

Definition  5.  A  functional  F  :  IR"  x  .F  — >  IR  is  called  majorant-computable  if  there  exists  effective  sequence  of 
sets  {TJgjgga,,  where  each  element  Rg  is  S-definable  by  an  effective  procedure  (ps  and  Il-definable  by  an  effective 
procedure  ips,  such  that  the  following  properties  hold: 

1.  For  all  s  &(jj,  the  set  Rs{x,  -  ,  /)  is  a  nonempty  interval; 

2.  For  all  x  G  M"  and  f  €  F,  the  sequence  {Rg{x,-,  f)}seui  decreases  monotonically; 

3.  For  all  (x,  /)  G  dom(F),  F(x,  f)  -  y  ^  Fs(x,  •,  /)  =  {1/}  holds. 

3  Specifications  of  Hybrid  Systems 

Let  us  consider  hybrid  systems  of  the  type  considered  in  Introduction.  A  specification  of  the  hybrid  system 
SHS  =  {TS,  F,  Convl,  A,  Conv2, 1)  consists  of: 

•  r5  =  .  It  is  an  effective  sequence  of  real  numbers.  The  real  numbers  ti  are  the  times  of  communication 

of  the  external  world  and  the  hybrid  system,  and  the  plant  and  the  control  automata.  The  time  sequence 
{ti}ieu)  satisfies  the  realizability  requirements: 

1.  For  every  i,  t*  >  0; 

2.  to  <ti  <...  <ti...] 

3.  The  differences  f  —  ti  have  positive  lower  bounds. 

•  F  :  HW(]R)  X  F  ->  IR.  It  is  a  majorant-computable  functional.  The  behaviour  of  the  plant  is  modelled  by 
this  functional. 

•  Convl  :  IM  X  A*.  It  is  an  effective  procedure.  At  the  time  of  communication  this  procedure  converts 

the  number  of  time  interval,  measurements  presented  by  two  F-formulas  into  finite  words  which  are  input 
words  of  the  internal  control  automata. 

•  A  :  A*  A*.  It  is  a  F-definable  function.  The  internal  control  automata,  in  practice,  is  a  finite  state 
automata  with  finite  input  and  finite  output  alphabets.  So,  it  is  naturally  modelled  by  F-definable  function 
(see  [5,8,12])  which  has  a  symbolic  representation  of  measurements  as  input  and  produces  a  symbolic 
representation  of  the  next  control  law  as  output. 
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•  Conv2  :  A*  ->■  HW(]R).  It  is  a  i7-definable  function.  This  function  converts  finite  words  representing  control 
laws  into  control  laws  imposed  on  the  plant. 

•  I  C  A*  U  HW(1R,).  It  is  a  finite  set  of  initial  conditions. 

Theorem  1.  Suppose  a  hybrid  system  is  specified  as  above.  Then  the  trajectory  of  the  hybrid  system  is  defined 
by  a  majorant-computable  functional. 


Proof  Let  SHS  =  (T S,  T,  Convl,  A,  Conv2, 1)  be  a  specification  of  the  hybrid  system.  We  consider  behaviour 
of  the  hybrid  system  m  terms  of  our  specification  on  [U,  U+i].  Let  J^{ti,  z,  /)  =  pi,  where  represents  the  recent 
control  law  ,  and  pi  is  the  state  of  the  plant  at  the  time  tj. 

At  the  moment  U  Converter  1  gets  measurements  of  recent  states  of  the  plant  as  input.  By  properties  of 
majorant-computable  functionals,  these  measurements  can  be  presented  by  two  ^-formulas  which  code  methods 
of  computations  of  measurements.  These  representations  are  compatible  with  real  measurements.  Indeed,  using 
different  approaches  to  process  some  external  signals  from  the  plant.  Converter  1  may  transform  it  to  different 
results.  This  note  is  taken  into  account  in  our  formalization  of  Converter  1  .  Thus,  Ccmvl  is  a  X'-definable 
function  and  its  arguments  are  the  methods  of  computations  of  measurements.  The  meaning  of  the  function 
Convl  is  an  input  word  Wi  of  the  digital  automaton  which  is  presented  by  A.  By  wi  the  function  A  computes 
new  control  law  W2  and  Conv2  transforms  it  to  z. 

The  plant  transforms  new  information  about  external  world  presented  by  /  to  recent  states  of  the  plant 
according  to  the  control  law  i,  i.e.,  y  =  J^{t,zj)  for  t  e  [tiA+i].  The  theorem  states  that  there  exists  a 
majorant-computable  functional  F  such  that  y{i)  =  F{t,  f). 

By  Definition,  F(t,  z,  f)  is  majorant-computable  functional.  Denote  the  initial  time  by  to  and  the  initial 
position  of  the  plan  by  j/q.  Let  /  be  a  majorant-computable  function,  and  O  be  its  ordinate  set,  E  be  its  epigraph 
By  the  properties  of  majorant-computable  functionals  (see  [13,14]  )  there  exist  two  effective  procedures  h,  ho 

cnph  •c'  J-5 


Fix,f)=:y^  hiiO,E)(x,-)  <  y  <  h2iO,E){x,-)  and 
{z\h,{0,E)ix,z)}U{z\h2iO,E){x,z)}  =  M\{y} 
Denote  ^  (y  >  y^) ,  ^  (y  <  .  For  t  €  [to,  h]  put; 

(pi{0,E){t,y)  Bwi3w23a[Convl{l,F^,^Q)  =  wi  A  A(«ji)  =  uia  A 

C onv2{w2 ,a)  A  hi{0,E){t,  a,  y)], 
(l>2iO,E){t,y)  ^  3wi3w23a[Convl{l,^+,$-)  =  wi  AA(wi)  =  w2  A 

Conv2{w2  ,a)Ah2  (O,  E)  (t,  a,  y)] . 

In  the  same  way  we  can  construct  the  procedure  ^63  for  each  interval  [ti,ti+i].  Put 

Pit.  f)=y^^i  (O,  E)(t,  ■)<y<  </>2(0,  E)(t,  •)  and 
{z  I  ^i(0,E)(t,z)}  U  {z  I  ,f>2(0,E)(t,z)}  =  H  \  {y} 


By  constructions,  the  functional  F  is  majorant-computable  and  defines  the  trajectory  of  the  hybrid  system  with 
olib  specmcation.  ^  j  ^ 

This  paper  has  presented  the  description  of  trajectories  in  terms  of  majorant-computable  functionals  which 
can  be  constructed  by  the  specifications  SffS  of  hybrid  systems.  The  preliminary  results  suggest  possible 
directions  for  future  applications  to  study  real  hybrid  systems. 
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Abstract.  Algebraic  imperative  specifications  (AIS)  are  specifications  with  implicit  state  represented  by 
an  algebra  and  with  a  number  of  transition  rules  indicating  state  transformations.  They  are  designed  for 
the  formal  definition  of  complex  dynamic  systems. 

Two  approaches  to  algebraic  imperative  specifications  have  been  developed  in  parallel  during  the  last 
decade:  Abstr^t  State  Machines  (ASMs),  initially  known  as  evolving  algebras,  and  Algebraic  Specifications 
with  Implicit  State  (AS-IS).  Moreover  typed  versions  of  ASM  have  been  developed  which  have  incorporated 
SOni6  35p6CtS  01  AS~IS. 

This  survey  paper  provides  a  guided  tour  of  these  imperative  approaches  of  specification  based  on  the 
state-as-dgebra  paradigm,  and  sketches  a  synthesis  of  two  of  them,  under  the  name  of  dynamic  systems 
with  implicit  state.  ^ 


1  Introduction 

Algebraic  imperative  specifications  (AIS)  are  specifications  with  implicit  state  represented  by  an  algebra  and 
with  a  number  of  transition  rules  indicating  state  transformations.  They  are  designed  for  the  formal  definition 
of  complex  dynamic  systems. 

and^dlna  W  system  to  be  implemented  in  some  programming  language  usually  possesses  static 

d  dynamic  features.  The  static  features  are  represented  by  a  number  of  data  types  involved  and  a  number  of 
functions  defined  over  them.  The  dynamic  features  are  represented  by  a  number  of  states  the  system  can  be  in 
and  a  number  of  operations  (procedures,  modifiers)  transforming  the  states. 

Conventional  algebraic  specifications  [12, 13, 38]  have  proved  to  be  an  elegant  and  effective  way  of  defining 
the  static  aspects  of  such  a  system.  Using  this  technique,  one  can  define  a  number  of  data  types  (sets  with 
corresponding  operations)  and  functions  just  by  providing  a  signature  (i.e.,  the  names  of  sorts,  and  the  names 
of  operations  accompanied  by  their  profiles)  and  a  set  of  axioms  limiting  the  set  of  possible  models.  These  data 
types  and  operations  can  be  further  used  in  the  system  specification. 

However,  algebraic  specifications  are  less  convenient  in  defining  the  dynamic  aspects  of  a  system  In  this 
c^ejhe  state  has  to  be  dehned  in  some  way  (Cor  exantple,  as  a  coniplex  La  type)Ld  its  ^0"  havfto 
be  explicitly  used  as  arguments  and/or  results  in  operations  transforming  one  state  into  another.  As  a  result 
the  specification  becomes  very  clumsy:  it  is  difficult  both  to  write  and  read. 

In  parallel  with  ^gebraic  specifications,  a  number  of  methods  involving  the  notion  of  built-in  state  have 

arTvOM  fflfaTd  f  137  371 state.  The  most  well-known  of  them 
are  VDM  [31]  and  Z  [36,37].  (See  [35]  for  a  good  review.)  One  of  the  latest  developments  in  the  field  is  B  [1]. 
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The  main  idea  of  each  of  these  methods  is  that  all  the  operations  transforming  the  state  can  be  characterized 
by  observing  their  effect  on  a  number  of  variables  (variables  are  understood  here  in  the  same  way  they  are 
understood  in  programming  languages)  representing  components  of  the  system’s  state.  Therefore,  the  variable 
value  before  the  operation  and  after  its  execution  is  taken  into  account  and  a  relation  between  these  two  values  is 
specified.  It  is  done  by  a  logical  formula  relating  pre-operation  and  post-operation  values  of  one  or  more  variables 
in  Z,  by  giving  two  formulas  specifying  the  condition  to  be  satisfied  by  the  variables  before  the  operation  (pre¬ 
condition)  and  the  condition  to  be  satisfied  by  them  after  the  operation  execution  (post-condition)  in  VDM, 
and  by  substitution  rules  in  B.  For  this  purpose,  special  decoration  is  normally  proposed  for  indicating  variable 
values  before  the  operation  and  after  it  (hooks  for  pre-operation  values  in  VDM  and  primes  for  post-operation 
values  in  Z). 

A  common  feature  of  the  three  methods  is  their  use  of  a  fixed  number  of  basic  types  and  type  constructors 
for  the  representation  of  application  data.  The  usual  basic  types  are  integers  (with  their  subsets)  and  scalars 
given  by  enumerations.  The  usual  type  constructors  are  set  constructor,  tuple  constructor  and  several  kinds  of 
function  constructors.  VDM  restricts  the  set  of  function  constructors  to  finite  maps  (i.e.,  partial  functions  with 
a  finite  domain)  and  offers  a  sequence  constructor  in ,  addition.  Z  allows  the  definitions  of  binary  relations  in 
addition,  and  B  does  not  possess  a  tuple  constructor. 

Another  common  feature  of  these  methods  is  that  some  parts  of  the  semantics  of  some  basic  notions  remain 
informal.  For  example,  the  formal  definition  of  “a  simple  and  powerful  specification  language  closely  similar  to 
the  Z  notation”  in  [36]  does  not  explain  the  notion  of  state  intensively  used  in  its  informal  semantics.  There,  a 
not-producing-result  operation  is  said  to  transform  the  state  while  its  formal  specification  just  sets  some  relations 
among  primed  and  non-primed  names  in  a  model  of  the  signature  induced  by  the  operation  specification.  In 
VDM  and  B  such  notions  as  state,  variable,  and  operation  are  also  introduced  informally:  it  is  assumed  that 
they  are  well  understood  by  those  who  write  specifications  and  those  who  read  them. 

However,  if  we  say  “constant”  instead  of  “variable” ,  we  can  regard  the  state  as  an  algebra  with  a  number  of 
defined  constants  and  functions,  and  we  can  regard  primed  and  non-primed  (or  hooked  and  non-hooked)  names 
as  denotations  of  the  same  constant  name  in  two  different  algebras.  In  this  case,  we  can  say  that  a  formula 
relates  values  associated  with  a  given  constant  name  in  two  algebras,  and  an  operation  updating  the  state  can 
be  defined  as  an  algebra  transformation.  Moreover,  if  we  specify  the  state  as  an  algebra,  we  can  delete  the 
limitations  on  the  sets  of  data  types  involved.  In  the  specification  of  a  particular  application,  those  data  types 
are  defined  which  are  practically  needed  in  the  application.  All  the  power  of  the  algebraic  specifications  can  be 
used  in  this  case. 

The  introduction  of  the  notion  of  algebra  update  as  a  transition  from  one  state  to  another  naturally  leads 
us  to  such  form  of  specification  which  explicitly  indicates  in  which  way  a  con.stant  (a  function  in  the  general 
case)  is  updated  in  the  process  of  algebra  transformation.  No  decoration  of  names  is  needed  in  this  case.  In 
parallel  with  imperative  languages,  we  call  this  kind  of  specifications  algebraic  imperative  specifications  (AIS). 
The  word  algebraic  emphasizes  the  algebraic  nature  of  the  state;  the  word  imperative  suggests  an  analogy  with 
imperative  languages. 

AIS  may  be  used  for  describing  algorithms;  every  step  of  an  algorithm  can  be  regarded  as  a  transition 
from  one  state  to  another  simulated  at  the  most  appropriate  abstraction  level.  Imperative  specifications  may 
be  also  used  for  describing,  in  an  abstract  and  non  algorithmic  way,  dynamic  features  of  a  system:  each  state 
transforming  operation  is  described  in  terms  of  some  complex  algebra  updates. 

Finally,  it  is  generally  accepted  that  the  ease  (or  difficulty)  of  the  implementation  of  a  specification  heavily 
depends  on  its  structure  and  complexity.  Since  the  majority  of  the  programs  are  written  in  imperative  languages, 
there  is  much  more  chance  that  a  specification  will  be  read  and  implemented  by  a  programmer  if  it  is  imperative. 
This  feature  relates  AIS  to  some  other  specification  languages  which  could  also  be  called  imperative  but  not 
algebraic  [1,6]. 

Two  approaches  to  algebraic  imperative  specifications  have  been  developed  in  parallel  during  the  last  decade: 
Abstract  State  Machines  (ASMs),  initially  known  as  evolving  algebras  [28, 29],  and  Algebraic  Specifications  with 
Implicit  State  (AS-IS)  [8,33].  The  main  features  of  AS-IS  are  presented  in  the  next  section.  Basic  notions  of 
ASM  and  its  typed  versions  are  described  in  Section  3.  Dynamic  systems  with  implicit  state  combining  some 
features  of  the  both  approaches  are  presented  in  Section  4.  Some  related  work,  all  based  on  the  state-as-algebra 
idea,  is  discussed  in  Section  5  and  some  conclusions  are  given  in  Section  6. 

2  Algebraic  specifications  with  implicit  state 

The  origins  of  this  approach  go  back  to  the  1980’s,  to  some  work  on  compiler  construction  from  some  formal 
semantics  of  the  source  and. target  languages  [14, 15].  There,  the  semantics  of  imperative  languages  was  modeled 
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by  state  transformations,  where  the  states  were  many-sorted-algebras.  In  the  area  of  programming  language 
semantics,  other  approaches  generally  model  states  as  functions,  which,  roughly,  go  from  some  kinds  of  names 
into  some  kinds  of  values,  the  domain  and  co-domain  of  these  state  functions  being  unions  of  sets.  Such  ap¬ 
proaches  become  clumsy  when  values  of  complex  data  types  have  to  be  stored  and  modified:  some  operations 
on  names  must  mimic  the  operations  on  the  data  types  (such  as  accesses  to  components  and  constructors)  and 
adequate  commutativity  properties  must  be  maintained  when  modifying  the  state.  In  [14],  it  was  shown  how 
to  use  many  sorted  algebras  as  models  of  such  states,  based  on  the  classical  idea  that  data  types  are  algebras. 
Some  extensions  were  invented  to  take  into  account  the  notion  of  variables,  assignments  being  modeled  as  trans¬ 
formations  of  algebras.  The  advantage  of  such  a  framework  for  compiler  specification  is  that  the  representation 
of  the  source  data  types  by  some  target  data  types  can  be  proved  using  the  techniques  developed  for  algebraic 
specifications  .[15]. 

Some  years  later,  this  first  approach  served  as  the  inspiration  for  AS-IS,  Algebraic  Specifications  with  Implicit 
State.  The  motivation  for  the  design  of  AS-IS  was  a  case  study  on  the  formal  specification  of  the  embedded 
safety  part  of  an  automatic  subway  pilot  [9,10].  The  specified  system  was  a  classical  control-command  loop, 
where  the  body  of  the  loop  receives  some  inputs,  performs  some  computations,  and  returns  some  outputs! 
Inputs  come  from  some  sensors  or  some  ground  controller.  Outputs  are  alarms,  commands,  or  messages  to 
the  pound  controller.  The  first  formal  specification  was  written  in  a  pure  algebraic  style,  using  the  PLUSS 
specification  language  [16].  It  turned  out  that  the  state  of  the  system  was  characterized  by  54  values  of  various 
types  (abscissa,  speed,  next  train,  tables, . . . ).  Most  of  these  values  were  liable  to  be  updated  during  some  cycles 
of  the  loop.  As  a  consequence,  the  specification  contained  54  observer  operations  of  the  state,  i.e.  operations 
of  profile  state  x  . . .  y  s,  where  s  is  a  sort  different  from  state,  and  54  update  operations,  i.e.  operations  of 
profile  state  x  . . .  x  s  state.  A  long  and  uninteresting  axiomatization  of  these  108  operations  was  needed.  In 
order  to  shorten  the  specification,  a  predefined  notion  of  record,  similar  to  the  one  in  VDM,  was  introduced  in 
the  specification  language.  However,  it  was  still  boring  and  redundant  to  have  states  as  parameters  everywhere. 
This  has  led  to  the  introduction  of  a  concept  of  implicit  state  in  the  algebraic  specification  language.  Of  course, 
such  a  notion  must  not  be  limited  to  the  special  case  of  a  record.  Actually,  it  must  be  possible  to  specify  any 
kind  of  data  structure,  at  different  abstraction  levels,  and  any  evolution  concerning  the  implicit  state. 

Another,  more  complex,  case  study  was  then  performed  [17],  namely  the  Steam-Boiler  Control  Problem.  It 
has  led  to  some  addition  to  the  formalism,  in  order  to  avoid  too  algorithmic  specifications  of  complex  evolutions 
of  the  system.  The  most  recent  version  of  AS-IS  is  presented  in  [32]. 

An  AS-IS  specification  is  based  on  a  classical  algebraic  specification  which  describes  the  data  types  to  be  used 
by  the  system.  This  part  is  clearly  isolated  in  the  specification  and  its  meaning  is  stable,  whatever  modification 
of  the  state  is  specified  .  The  evolving  parts  of  the  implicit  state  are  specified  as  access  functions  whose  results 
depend  on  the  implicit  state. 

Example.  In  a  subway  example,  there  may  be  the  following  access  functions  which  correspond  to  the  section 
of  the  railway  where  the  train  is  currently  located,  and  a  table  where  the  speed  limit  for  each  section  is  stored. 

Current  Section  : — y  Section 

Local SpeedLimit :  Section  — y  Speed 
where  the  Section  and  Speed  types  are  specified  in  the  data  type  part  . 

The  evolutions  of  the  implicit  state  are  described  by  modifications  of  the  access  functions. 

Example.  When  the  train  progresses,  one  may  have 

Currents ection  :=  next{CurrentSection) 
or  when  the  weather  conditions  change 

Vs  :  Section,  Local SpeedLimit{s}  :=  Local SpeedLimit{s)  -  10 

^t  i;  be  the  signature  of  the  data  types.  Ax  their  axioms,  and  the  part  of  the  signature  corresponding 
to  the  names  and  profiles  of  the  access  functions.  A  state  is  any  <  T  U  T,,,  Ax  >-algebra.  A  modification  is  a 
mapping  trom  the  <  UU  Sac,  Ax  >-algebras  into  themselves  where  the  interpretation  of  some  access  functions 
of  the  resulting  algebra  are  different  from  their  interpretations  in  the  source  one.  The  example  modifications 
above  are  called  elementary  since  each  of  them  involves  one  access  function  only. 

In  addition  to  the  elementary  accesses,  such  as  the  ones  above,  which  characterize  the  implicit  state  there 
are  dependent  accesses  which  are  related  by  some  property  to  the  other  accesses. 

Example.  One  may  define 

Current  SpeedLimit : — y  Speed 

CurrentSpeedLimit  =  niin^Local SpeedLimit{CurrentSection') , . . .) 


This  implies  that  the  carriers  remain  invariant. 
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Among  the  design  choices  of  AS-IS,  it  was  decided  to  keep  the  specified  behaviors  deterministic.  In  order 
to  ensure  this,  the  dependent  accesses  must  be  defined  by  a  set  of  axioms  which  is  sufficiently  complete  with 
respect  to  the  elementary  accesses  and  data  types.  Thus  an  AS-IS  specification  includes,  in  addition  to  the 
specification  of  some  data  tjrpes  with  signature  E  satisfying  some  axioms  Ax,  some  elementary  access  functions 
whose  names  and  profiles  are  given  in  a  sub-signature  Eeac,  some  dependent  access  functions  specified  by  a 
sub-signature  S^ac  and  some  axioms  Axac-  Lot  E'  SV)  Eeac  U  Ej,ac-  Then  a  state  is  any  <  E' ,  Ax  U  Axac  >■ 
algebra. 

The  semantics  of  elementary  modifications  is  based  on  restrictions  and  extensions  of  the  state  algebras.  First, 
all  the  dependent  accesses  are  forgotten.  Then,  if  ac  is  the  name  of  an  elementary  access  being  modified,  the 
algebra  is  extended  by  the  new  elementary  access  ac',  with  the  same  profile  as  ac,  which  is  different  from  ac  for 
the  values  of  the  arguments  specified  in  the  modification  (see  below)  and  the  same  everywhere  else.  Then  ac 
is  forgotten,  ac'  is  renamed  ac,  and  the  algebra  is  extended  to  include  the  dependent  accesses  and  satisfy  the 
corresponding  axioms. 

In  an  AS-IS  specification,  as  soon  as  an  elementary  access  oc  :  si  x  . . .  x  s„  — >■  s  is  declared,  it  is  possible 
to  write  elementary  modifiers  of  the  form 

Va:i  :  s'l , . . . ,  Xp  :  Sp,  [ac(7ra , . . . ,  7r„)  :=  i?(7ri , . . . ,  7r„)] 

where  the  Trj  are  terms  of  Te'Uxi,.  ■ .  ,Xp}),  of  sort  Sj,  which  play  a  role  similar  to  patterns  in  functional 
programming,  and  Rljri 7r„)  is  a  term  built  with  the  constants  of  E',  the  tti,  and  the  operations  of  S'.  Such 
a  modifier  induces  the  modification  of  the  result  of  ac  for  all  the  values  matching  the  patterns,  i.  e.,  if  A  is  the 
original  state  and  B  the  modified  one,  we  have: 

Vvi,...,u„  in  As,  X  ...  X 

-  if  there  exists  an  assignment  a  of  the  Xi  into  A*; ,  such  that  a{'Ki)  =  vi, .. .  ,a{'Kn)  —  Vn,  then 

oc®  (ui ,...,  u„)  =  jR(a(7ri ),...,  S(7r„)) 

-  otherwise 

ac^{vi,...,Vn)  =  ac^{vi,...,Vn). 

In  the  above  example  a  quantified  elementary  modifier  is  used  to  specify  a  global  change  of  the  local  speed 
limits. 

There  is  a  conditional  version  of  such  modifiers,  with  the  same  restriction  on  the  form  of  the  conditions  as 
on  the  result  :  they  must  involve  the  only. 

Vyi,..., 2/p  cases 

<^i  then  ac(7ri, . . .  ,7r^)  :=  i?^| . . .  I  ^!>m  then  oc(7r]”, . . .  ,7rjf)  :=  i?” 
end  cases 

The  restrictions  on  the  form  of  the  conditions  and  results  ensure  that  only  one  result  is  specified  for  each 
item  of  the  domain  of  the  elementary  access  being  modified.  Counter-examples  justifying  these  restrictions  are 
given  in  [19]. 

Elementary  accesses  can  be  used  to  specify  defined  modifiers.  Defined  modifiers  are  specified  by  compositions 
of  elementary  modifiers  and  defined  modifiers.  The  compositions  are 

—  Conditional  composition  of  the  following  form: 

begin  then  Emi  |  . . .  j  ^p  then  Emp  end 

indicating  that  a  modification  expression  Em^  is  chosen  if  its  condition  (j)i  is  valid.  If  several  conditions  (j), 
are  valid,  the  modification  expression  with  the  smallest  index  is  chosen. 

Note:  This  form  of  modification  is  different  from  the  conditional  elementary  modifier  in  two  ways:  the  Em, 
are  any  modification  expressions  and  there  are  no  universally  quantified  variables. 

—  Sequential  composition,  mi]  m2,  meaning  that  the  execution  of  mi  is  followed  by  that  of  m2. 

—  Casually  independent  composition,  mi  and  m2,  indicating  any  sequential  composition  of  mi  and  m2.  The 
order  of  execution  of  mi  and  m2  is  unimportant. 

—  Simultaneous  composition,  mi  •m2,  where  the  modifications  specified  by  mi  and  m2  are  applied  to  the  same 
state.  If  mi  and  m2  specify  a  modification  of  the  same  access  function,  they  must  change  it  at  different 
points;  otherwise,  only  the  modification  mi  is  taken  into  account. 

This  list  does  not  aim  at  being  minimal.  Actually,  some  constructs  overlap  in  some  cases.  It  aims  to  provide 
a  convenient  way  of  specifying  complex  state  modifications,  without  worrying  about  details  such  as  intermediate 
results  or  order  of  execution  when  they  are  not  relevant  to  the  specification. 

Thus  defined  modifiers  are  declared  with  a  profile  which  states  the  sorts  of  their  arguments,  and  their  effect 
on  the  state  is  described  by  a  modification  expression. 
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Example. 

switchSpeedLimits  :  Speed 
switchSpeedLimits{As)  =  Vs  :  Section, 

[Local SpeedLimit{s)  :=  Local SpeedLimit{s)  -  As] 

Defined  modifiers  and  access  functions  may  be  exported  by  a  system  specification.  When  using  a  system 
specihcation,  only  the  exported  features  can  be  mentioned.  This  ensures  some  encapsulation  of  the  implicit 

specification  also  contains  a  set  of  axioms  Axinu  which  specifies  possible  initial  states  of  the 
specified  system.  The  behaviors  of  the  system  are  sequences  of  exported  instantiated  modifiers,  i.  e.  exported 
etaed  rnodmers  with  ground  terms  as  arguments,  or  elementary  modifiers  of  exported  accesses  with  parameters 
either  quantified  or  instantiated  by  ground  terms.  A  reachable  state  of  the  system  is  either  an  initial  state,  or 
t  e  resulting  state  of  an  exported  instantiated  modifier  applied  to  a  reachable  state. 

example  of  a  system  specification  is  given  below.  It  is  a  drastic  (and  thus  unrealistic)  simplification  of 
the  specification  presented  in  [10]. 

The  specified  system  can  progress,  with  a  measured  speed,  during  an  interval  of  time  At,  or  the  speed  limits 
of  the  sections  can  be  chanpd  via  the  switchSpeedLimits  modification,  or  an  emergency  stop  can  occur. 

The  progress  modification  is  the  most  complex  one.  It  checks  that  the  speed  limit  is  respected.  If  it  is  not 
an  emergency  stop  occurs,  and  if  it  is,  the  system  deals  with  a  possible  section  change,  chooses  an  acceleration 
which  depends  on  the  current  speed  (this  choice  is  not  specified  here),  and  computes  the  next  position  of  the 

tirctin.. 

system  TRAI N  export  progress,  emergency  Stop,  switchSpeedLimits 
use  UNITS,  /c  defines  the  sorts  Abscissa,  Speed,  and  Acceleration 
%  and  some  constants  of  these  sorts 
SECTION  %  defines  the  Section  sort 
elementary  accesses 

CurrentSection  : — y  Section, 

Local SpeedLimit :  Section  — >  Speed, 

MeasuredSpeed : — y  Speed, 

CurrentAbscissa  : — y  Abscissa, 

CurrentAcceleration  : — y  Acceleration 
accesses 

CurrentSpeedLimit : — y  Speed, 
accesses  axioms 

CurrentSpeedLimit  =  m,in{LocalSpeedLimit{CurrentSection), . . .) 

Init  ’ 

CurrentSection  =  sectionO,  LocalSpeedLimit{s)  =  speedlimO, 

MeasuredSpeed  =  speedQ,  CurrentAbscissa  =  0, 

CurrentAcceleration  =  accO, 
modifiers  %declaration  of  some  defined  modifiers 
progress  ;  Speed, 
emergency  Stop, 
switchSpeedLimits  :  Speed, 
sectionChange, 
accelerationC  hoice, 
modifiers  definitions 
progress{s)  = 

MeasuredSpeed  :=  s  and  CurrentAbscissa  NextAbscissa  ; 

begin 

CurrentAbscissa  >  length{CurrentSection)  then  sectimChange 

end  ; 
begin 

MeasuredSpeed  >  CurrentSpeedLimit  then  emergencyStop  | 

MeasuredSpeed  <  CurrentSpeedLimit  then 
accelerationC  hoice  ; 

N  ext  Abscissa  CurrentAbscissa+ 

[CurrentSpeed  +  CurrentAcceleration  x  At)  x  At, 
end  ’ 


Gaudel  M.-C.,  Zamulin  A.  Algebraic  Imperative  Specifications 


17 


switchSpeedLimits{As)  =  'is  :  Section, 

[LocalSpeedLimit{s) LocalSpeedLimit{s)  -  /Is] 
sectionChange  — 

CurrentSection  ~  next{CurrentSection)  • 

CurrentAbscissa  :=  CurrentAbscissa  —  length{CurrentSection) 
%  NB  :  it  is  much  more  complex  in  reality  . . . 
accelerationChoice  =  . . . 
emergency  Stop  =  . . . 
end  system 


3  Abstract  State  Machines 

3.1  Gurevich  Abstract  State  Machines 

Abstract  State  Machines  (ASMs),  originally  known  as  evolving  algebras,  have  been  proposed  by  Gurevich  [25] 
as  a  framework  for  the  formal  definition  of  the  operational  semantics  of  programming  languages.  During  the  last 
decade  many  real-life  programming  languages  and  many  complex  algorithms  including  communication  protocols 
and  hardware  designs  have  been  defined  as  ASMs  (the  first  complete  description  of  the  evolving  algebra  approach 
is  contained  in  [28],  the  annotated  bibliography  of  the  majority  of  papers  in  the  field  can  be  found  in  [5],  for 
the  most  recent  developments  look  at  http://www.eecs.umich.edu/gasm/). 

The  success  of  the  approach  can  be  attributed  to  two  reasons:  (1)  sound  mathematical  background  and  (2) 
imperative  specification  style.  The  imperative  nature  of  evolving  algebras  has  led  to  the  introduction  of  a  new 
term  for  them,  Abstract  State  Machines  (the  terms  Gurevich  Abstract  State  Machines  or  just  Gurevich  Machines 
are  also  in  use).  The  latest  version  of  ASM  is  described  in  [29]  which  is  used  as  the  main  reference  source  in 
this  section. 

ASMs  are  based  on  the  notion  of  a  universal  algebraic  structure  consisting  of  a  set,  a  number  of  functions, 
and  a  number  of  relations.  Such  a  structure  serves  for  the  representation  of  the  state.  The  underlying  set  is 
called  a  super-universe  and  can  be  subdivided  into  universes  by  means  of  unary  relations.  A  universe  serves  to 
model  a  data  type  (in  fact,  the  set  of  data  type  values). 

There  are  a  number  of  transition  rules  indicating  in  which  way  a  state  can  be  converted  into  another  state 
of  the  same  signature.  Normally,  this  is  done  by  a  slight  change  of  a  function.  For  this  reason,  functions  can  be 
either  static  or  dynamic.  A  static  function  never  changes,  a  change  of  a  dynamic  function  produces  a  new  state. 
Another  means  of  state  modification  is  changing  the  number  of  elements  in  the  underlying  set  (importing  new 
elements). 

Only  total  functions  are  used  in  Gurevich  ASM.  A  distinguished  super-universe  element  undef  is  used  to 
convert  a  partial  function  into  a  total  one.  Thus,  every  r-ary  function  /  is  defined  on  every  r-tuple  a  of  elements 
of  the  super-universe,  but  they  say  that  /  is  undefined  at  an  o  if  /(a)  =  undef,  the  set  of  tuples  a  with 
/(a)  /  undef  is  called  the  domain  of  /. 

The  other  two  distinguished  super-universe  elements  are  true  and  false.  The  interpretation  of  an  r-ary 
predicate  (relation  name)  U,  defined  on  the  whole  super-universe,  with  values  in  {true,  false}  is  viewed  as  a 
set  of  r-tuples  d  such  that  UifS)  =  true.  If  relation  U  is  unai’y,  it  can  be  viewed  as  a  universe. 

The  vocabulary  (signature)  of  any  ASM  contains  the  names  of  the  above  three  distinguished  elements,  the 
name  of  the  universe  Boole  defined  as  {true,  false],  the  names  of  the  usual  Boolean  operations  interpreted 
conventionally,  and  the  equality  sign  interpreted  as  the  identity  relation  on  the  super-universe.  All  the  functions 
corresponding  to  the  above  names  are  static. 

Example.  The  vocabulary  for  oriented  trees  contains  a  unary  predicate  Nodes  and  unary  function  names 
Parent,  FirstChild,  and  NextSibling.  An  oriented  tree  with  n  nodes  gives  rise  to  a  state  with  n  -f  3  elements:  in 
addition  to  n  nodes,  the  super-universe  contains  the  obligatory  elements  true,  false,  undef  The  universe  Nodes 
contains  the  n  nodes. 

For  the  interpretation  of  transition  rules,  the  notions  of  location,  update,  and  update  set  are  introduced.  A 
location  in  a  state  A  is  a  pair  I  =  (/,5),  where  /  is  a  function  name  of  arity  r  and  a  is  an  r-tuple  of  elements 
of  A.  In  the  case  that  /  is  nullary,  (/,  ())  is  abbreviated  to  /. 

Example.  Assume  that  we  have  an  oriented  tree  and  let  a  be  a  node,  then  some  locations  axe  {Parent,  a), 
{FirstChild,  a),  {NextSibling,  a) 

An  update  in  a  state  A  is  a  pair  a  =  {I,  b),  where  I  =  {f,d)  is  a  location  in  A  and  b  is  an  element  of  A.  To 
update  the  state  A  using  a  (“to  fire  a  at  A”),  it  is  necessary  to  “put  b  into  the  location  I”,  i.e.  convert  A  into 
a  new  algebra  B  so  that  /^(d)  =  b.  The  other  locations  remain  intact. 
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Example.  Assume  again  that  we  have  an  oriented  tree  and  let  a,  b  be  any  two  nodes,  then  some  updates 
are  {{Parent,  a),b),  {{FirstChild,  h),a). 

An  update  set  over  a  state  A  is  a  set  of  updates  of  A.  An  update  set  7  is  consistent  if  no  two  updates  in 
7  clash,  i.e.  there  axe  no  two  {h,b^)  and  {l2,b^)  such  that  h  =  h  but  ^  b^.  To  update  the  state  A  using  a 
consistent  7,  it  is  necessary  to  “fire  all  its  updates  simultaneously”.  The  state  does  not  change  if  the  update  set 
IS  inconsistent. 

The  transition  rule  (or  simply  “rule”  in  the  sequel)  called  update  rule  has  the  following  form: 
f{s)  :=  t, 

where  /  is  the  name  of  a  function  of  arity  r,  s  is  a  tuple  (si , ...,  s,)  of  terms,  and  t  is  a  term.  The  interpretation 
of  this  rule  m  a  state  A  causes  an  update  a  =  ((/,a),  t^),  where  d  =  (s(^, ...,  s^). 

Example  Assume  that  c  and  p  are  terms  denoting  two  nodes  of  an  oriented  tree.  Then  the  transition  rule 
parent{s)  p 

interpreted  in  a  state  A  by  the  update  {{parent,  s^),p^)  will  transform  A  in  5  so  that  parent^ {s^)  =  and 
the  other  locations  remain  intact. 

A  conditional  rule  having  the  form 

if  g  then  else  R2  endlf,  where  ^  is  a  Boolean  term  and  R,,R2  are  rules,  causes  the  execution  of 
either  Hi  or  R2  depending  on  whether  g  is  true  or  false. 

Another  basic  rule  is  a  block  constructed  as  follows: 

do  in-parallel  Ri, ...,  R^  enddo, 

where  are  rules.  The  block  rule  is  interpreted  by  an  update  set  consisting  of  updates  produced  by 

interpretations  of  i^j, ....  The  state  does  not  change  of  course  if  the  update  set  is  inconsistent 
The  last  basic  rule  is  an  import  rule  having  the  following  form: 
import  V  R{v)  endimport, 

where  u  is  an  identifier  and  R{v)  is  a  rule  using  this  identifier  as  a  free  variable.  The  interpretation  of  this  rule 
m  a  state  A  causes  the  extension  of  its  basic  set  (super-universe)  with  a  new  element  a  and  the  subsequent 
interpretation  of  with  v  bound  to  o.  It  is  supposed  that  different  imports  produce  different  reserve  elements 
For  example,  the  interpretation  of  the  block 
do  in-parallel 

import  V  Parent{v)  :=  c  endimport 
import  V  Parent{v)  c  endimport 
enddo 

creates  two  children  of  node  c. 

There  are  several  extensions  of  the  set  of  basic  rules.  A  try  rule  of  the  form 
try  Ri  else  R2  endif 

permits  some  form  of  exception  handling,  i.e.,  the  rule  R2  is  executed  only  if  Ri  is  inconsistent 
A  nondeterministic  choose  rule  of  the  form 
choose  V  :  g{v)  R{v}  endchoose, 

where  u  is  an  indentifier,  and  g{v)  and  R{v)  are,  respectively,  a  Boolean  term  and  a  rule  both  using  w  as  a  free 
rw  execution  of  R  only  for  some  one  element  of  the  superuniverse  satisfying  g.  This  means 

that  if  there  are  several  superuniverse  elements  such  that  g  evaluates  to  true  for  v  bound  to  any  of  them  then 
nondetermimstically  one  of  them  is  chosen  and  R  is  executed  with  v  bound  to  this  element. 

Finally,  a  do-forall  rule  of  the  form 
do  forall  v:  g{v)  R{v)  enddo 

of  ^  superuniverse  element  bound  to  u  and  satisfying  g.  In  this  way  the  quantification 

of  elementary  modifiers  and  conditional  elementary  modifiers  of  AS-IS  is  generalised  to  any  transition  rule 

syntactic  sugar  permitting  to  flatten  enclosed  conditional 
try  and  bloS  rdes,  ^c"  ^  ""  ""  necessary,  to  import  several  elements  in  an  import  rule,  combine 

important  to  note  that,  in  contrast  to  AS-IS  described  in  the  previous  section,  no  effort  is  made  to  ensure 
that  any  two  function  updates  do  not  update  the  same  function  at  the  same  point,  all  possible  inconsistences 

anrtriltn  rut.  quantification  can  be  applied  here  to 

stalm'rtoe'gi™  (npe]''™”  of  a 

“^chme  computes  expressions  given  in  reverse  Polish  notation,  or  RPN.  It  is  supposed  that  the 
RPN  expresjon  is  given  in  the  form  of  a  list  where  each  entry  denotes  a  number  or  an  operation  The  stS 
machine  reads  one  entry  of  the  list  at  a  time.  If  the  entry  denotes  a  number,  it  is  pushed  oto  the  taS  tf 
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the  entry  denotes  an  operation,  the  machine  pops  two  items  from  the  stack,  applies  the  operation  and  pushes 
the  result  onto  the  stack.  At  the  beginning,  the  stack  is  empty.  It  is  supposed  that  the  desired  ASM  has 
universes  Data  for  the  set  of  numbers  and  Oper  for  the  set  of  bynary  operations  on  Data.  Argl  and  Arg2  are 
distinguished  elements  of  Data.  To  handle  operations  in  Oper,  the  ASM  has  a  ternary  function  Apply  such  that 
Apply{f,  X,  y)  =  f{x,  y)  for  all  /  in  Oper  and  all  x,  y  in  Data. 

To  handle  the  input,  the  ASM  has  a  universe  List  of  all  lists  composed  of  data  and  operations.  The  basic 
functions  Head  and  Tail  have  a  usual  meaning.  If  L  is  a  list,  then  Head{L)  is  the  first  element  of  L  and  Tail{L) 
is  the  remaining  list.  F  is  a  distinguished  list  initially  containing  the  input.  Finally,  the  ASM  has  a  universe 
Stack  of  all  stacks  of  data  with  the  usual  operations  Push,  Pop,  and  Top.  S'  is  a  distinguished  stack  initially 
empty.  With  these  explanations,  the  specification  of  the  algorithm  looks  as  follows: 

if  Data{Head{F))  =  true  then 
do  in-parallel  S  :=  Push{Head{F),S) 

F  ~  TailiF) 

enddo, 

endif 

if  Oper{Head{F))  =  true  then 
if  Argl  —  undefthen 

do  in-parallel 

Argl  Top{S)  %  Argl  is  defined  now 
S  :=  Pop(S) 
enddo 

elseif  Arg2  =  undef  then 
do  in-parallel 

Arg2  :=  Top{S)  %  Arg2  is  defined  now 
S:=PopiS) 
enddo 

else 

do  in-parallel 

S~Push{Apply(Head{F),Argl,Arg2),S) 

F:=Tail{F) 

Argl  :=  undef  %  Argl  is  undefined  now 
Arg2  undef  %  Arg2  is  undefined  now 

enddo 

endif 


3.2  Typed  Abstract  State  Machines 

The  above  example  clearly  indicates  some  shortcomings  of  Gurevich  ASMs.  The  first  of  them  is  the  absence 
of  a  formal  definition  of  the  static  part  of  the  state.  Therefore,  it  is  defined  in  plain  words  (universes  Data, 
Stack,  List,  and  Oper,  operations  Head,  Tail,  etc.).  This  is  typical  of  ASM.  When  writing  a  specification,  one 
can  write  the  signature  of  any  function  operating  with  values  of  one  or  more  universes.  One  cannot,  however, 
define  formally  the  semantics  of  a  static  function  or  a  sufficiently  large  set  of  values  of  a  particular  universe.  It 
is  assumed  that  the  behavior  of  all  static  functions  is  either  well  known  or  defined  by  some  external  tools;  in 
the  majority  of  cases,  the  same  refers  to  universes  (one  can  make  sure  of  this,  looking  at  the  definition  of  C  [27] 
where  almost  all  static  functions  and  universes  are  defined  in  plain  words). 

The  second  shortcoming  is  the  actual  absence  of  a  type  system:  one  cannot  construct  arbitrary  data  types 
and  functions  with  a  well-defined  semantics  and  either  one  has  to  use  a  small  number  of  well-known  data  types 
like  Boolean,  Integer,  etc.  or  one  has  to  define  informally  needed  data  types  and  functions.  The  results  of  this 
shortcoming  are  well-known:  neither  an  appropriate  structuring  of  the  data  of  an  application  nor  type  checking 
of  a  specification  is  possible.  At  the  same  time,  a  big  specification  like  a  big  program  is  error-prone  and  type 
checking  helps  to  detect  many  errors  at  the  earliest  state  of  the  specification  development.  For  example,  the 
following  error  could  be  done  in  the  above  specification: 

S~Tail{F) 

Unfortunately,  no  formal  tool  is  able  to  detect  this  error,  and  it  can  be  only  debugged  with  the  use  of  a  concrete 
input  in  the  process  of  its  interpretation  if  an  interpreter  is  developed. 
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For  these  reasons  several  attempts  have  been  done  to  introduce  typing  in  ASMs.  The  first  proposal  is 
described  in  [39]  and  its  modification  in  [40],  An  Oberon  compiler  is  fully  specified  with  the  use  of  the  method 
[41].  A  distinguished  feature  of  the  approach  is  the  actual  proposal  of  a  specification  mechanism  incorporating 
the  advantages  of  both  many-sorted  algebraic  specifications  and  ASMs.  The  main  idea  behind  the  choice  of  basic 
specification  constructs  has  been  to  use  the  notions  most  familiar  to  the  programming  community.  Another  task 
has  been  avoidance  of  any  other  logic  except  the  first-order  many-sorted  logic  which  is  most  familiar  to  the 
computer  scientists. 

As  a  result,  universes  are  replaced  with  data  types  for  which  the  semantics  can  be  formally  defined  by 
means  of  algebraic  equations.  The  mechanism  provides  means  for  defining  both  concrete  data  types  and  type 
constructors  (generic,  or  parameterized  data  types).  Some  popular  data  types  and  type  constructors  are  built-in 
(these  are  enumeration  type,  record  type  and  union  type  constructors).  Data  type  operations  are  defined  together 
with  the  corresponding  sort  in  a  so  called  data  type  specification.  In  addition,  independent  static  functions  (i.e. 
functions  not  attributed  to  particular  data  types)  can  be  specified  with  the  use  of  data  type  operations. 

The  set  of  transition  rules  proposed  in  the  approach  is  mainly  based  on  the  set  of  basic  rules  of  [28].  There 
is,  however,  an  important  difference  in  the  treatment  of  the  assignment  of  an  undefined  value  to  a  location. 
There  cannot  be  a  single  undef  value  for  all  data  types.  To  simplify  the  specification  of  data  types,  no  one  of 
them  is  equipped  with  its  own  undef  value.  Partial  functions  are  used  instead,  and  a  definedness  predicate,  D, 
is  introduced.  For  each  term  t,  the  predication  D{t)  holds  in  a  given  algebra  A  if  i  is  defined  in  it  and  does ’not 
hold  otherwise.  In  an  update  rule 
fih,  —,tn)  •=  undef 

undef  is  just  a  keyword  indicating  that  /(tj,  ...,f„)  becomes  undefined. 

For  the  interpretation  of  such  a  construction,  another  algebra  update,  fi  is  introduced  in  addition  to  a 
described  above.  An  update  fi  is  just  a  location.  To  update  the  state  A  using  /3,  it  is  necessary  to  convert  A 
into  a  new  algebra  B  so  that  the  content  of  the  location  is  undefined.  The  other  locations  remain  intact. 

The  other  main  additions  are  sequence  constructor  and  a  tagcase  constructor  resembling,  respectively,  a 
compound  statement  and  a  tagcase  statement  of  some  programming  languages.  The  need  for  a  sequential  rule 
constructor  has  arisen  in  several  practical  applications  and  is  noted  in  [4,22].  They  are  also  part  of  AS-IS,  as 
described  in  the  Section  2.  The  tagcase  rule  constructor  is  needed  when  union  types  are  used.  It  has  the  followinff 
form:  ^ 

tagcase  u  otTi  .  Ri,  T2  :  R2,  .  .  .  ,  Tk  :  Rk  endtag 

where  u  is  a  term  of  type  Umon{Ti,T2,  ...,Tn),  Ri,R2,...,Rk  are  rules,  and  k  <=  n.  In  the  interpretaion  of 
the  rule,  the  component  type  of  u  is  compared  with  Ti,  ...Tk.  If  the  component  type  is  7),  then  is  executed 
regarding  «  as  a  term  of  type  7).  Thus,  the  tagcase  constructor  permits  us  to  manipulate  a  union  type  value  as 
a  value  of  the  type  needed  (this  facility  is  not  provided  by  the  conditional  constructor). 

To  demonstrate  the  facilities  of  the  approach,  we  rewrite  the  previous  example  of  a  stack  machine.  Notation: 
tte  data  type  signature  is  enclosed  in  square  brackets,  the  axioms  are  enclosed  in  curly  brackets,  the  symbol 
@  inside  the  data  type  signature  denotes  the  type  being  specified. 

type  Oper  =  (’-!-’,  %  enumeration  type 

type  Doper  =  UnionfNat,  Oper);  %union  type 

type  Stack  (T:  TYPE)  =  spec 
[empty: 

push:  T,  @  — 1 
pop:  @  — ¥ 
top:  ®  — ¥  T]; 

{axioms  are  conventional} 

type  List(T:  TYPE)  =  spec 
[empty:  ®; 

append:  T,  @  — ¥  ®; 
head:  ®  — >•  T; 
length:  ®  — ¥  Nat; 
tail:  ®  — >•  @; 
has:  @,  T  — ¥  Boolean; 
is.empty:  @  — ¥  Boolean] 

{axioms  are  conventional} 
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dynamic  const  S:  Stack(Nat)  =  empty;  initially  empty  stack 
dynamic  const  Argl,  Arg2:  Nat;  %  initially  undefined  constants 
dynamic  const  F:  List(Doper);  %  initialized  by  a  demon 

tagcase  head(F)  of 

Nat;  do  in-parallel  S  :=  push(head(F),  S),  F  ;=  tail(  F)  enddo, 

Oper: 

if  -iD(Argl)  then  %  if  Argl  is  undefined 
do  in-parallel  Argl  top(S),  S  pop(S)  enddo 
elseif  ->D(Arg2)  then  %  if  Arg 2  is  undefined 
do  in-parallel  Arg2  ;=  top(S),  S  ;=  pop(S)  enddo 
else 

do  in-parallel  S  :=  push  (apply  (head(F),  Argl,  Arg2),  S), 

F  :=  tail(F), 

Argl  ::=  undef,  %  Argl  is  undefined  now 
Arg2  ;=  undef  %  Arg2  is  undefined  now 

enddo 

endif 

endtag 

Note  that  all  the  operations  used  in  the  example  are  now  formally  defined  in  contrast  to  the  previous  version 
of  the  example.  Moreover,  a  type  checker  can  easily  detect  an  error  like  the  previous  one  and  even  one  like  the 
following  one  (which  cannot  be  detected  if  a  conditional  rule  were  used) : 

tagcase  head(F)  of 

Oper:  do  in-parallel  S  push(head(P),  S),  F  :=:  tail(F)  enddo, 


The  other  innovations  of  the  approach  are  dependent  functions  and  procedures  (defined  modifiers)  resembling 
the  corresponding  constructs  of  AS-IS.  However,  their  semantics,  as  it  is  defined  in  [43],  is  quite  different.  It  will 
be  explained  in  the  next  section. 

There  is  no  import  rule,  of  course.  In  a  typed  environment  where  each  algebra  element  is  denoted  by  (at  least 
one)  ground  term,  it  would  be  strange  to  manipulate  unreachable  elements  in  addition.  Some  technique  of  the 
specification  of  the  operations  as  dynamic  functions  could  help  to  solve  the  problem,  but  these  complications 
do  not  seem  necessary.  Structures  like  sets  or  lists  can  be  used  to  achieve  the  goal. 

Another  proposal  for  typed  ASMs  is  contained  in  [11].  In  contrast  to  the  approach  discussed  above,  this 
approach  does  not  confine  the  user  to  the  algebraic  style  of  defining  data  types.  Only  general  guidelines  of  a 
simple  type  system  introducing  parametric  polymorphism  as  suggested  in  [34]  are  given.  The  interpretation  of 
data  type  is  also  left  abstract.  The  only  requirement  is  that  every  closed  type  is  interpreted  as  a  set.  The  set 
of  rules  is  borrowed  from  [29]  with  the  exception  of  the  import  rule  which,  of  course,  is  not  needed  in  a  typed 
environment.  There  is  no  construct  corresponding  to  dependent  function  or  defined  modifier  of  AS-IS. 

Object-oriented  ASMs  as  a  kind  of  typed  ASMs  are  introduced  in  [42].  In  addition  to  a  number  of  data  types, 
such  an  ASM  uses  a  number  of  object  types.  While  a  data  type  defines  a  set  of  values  and  a  set  of  operations,  an 
object  type  defines  a  set  of  object  behaviors.  An  object  possesses  a  unique  identifier  and  a  number  of  methods 
subdivided  in  attributes  (correspond  to  dynamic  functions),  observers  (correspond  to  dependent  functions)  and 
mutators  (correspond  to  modifiers).  The  tuple  of  attribute  values  defines  the  object’s  state. 

For  a  given  object  type,  different  system’s  states  can  possess  different  numbers  of  objects  with  different 
object’s  states.  An  object’s  state  can  be  updated  with  the  use  of  a  mutator.  For  creating  new  objects  of  type 
T,  the  import  rule  of  Gurevich  ASMs  in  the  form  new{T)  is  reinvented.  Note  that  this  reinvention  does  not 
violate  the  term  generation  principle  mentioned  above  since  there  is  no  basic  term  generating  an  object  identifier 
(remember  that  an  object  type  defines  a  set  of  object  behaviors  rather  than  a  set  of  object  identifiers!). 

Object  types  are  specified  with  the  use  of  transition  rules.  Here  is  a  example  of  it  (method  profiles  and 
method  calls  are  written  like  in  object-oriented  programming  languages,  the  other  notation  is  like  that  one  used 
in  data  type  specifications,  two  parts  of  an  axiom  are  related  by  the  symbol  “==”): 

class  Rectangle  =  spec 

[mutator  default_rectangle;  %  setting  a  default  rectangle’s  state 
create:  Nat,  Nat;  %  setting  a  new  rectangle’s  state 


22 


Perspectives  of  System  Inforinatics’99 


attribute  length,  width:  Nat;  %  rectangle  attributes  definig  the  state 
observer  area:  Nat;  %  computing  a  rectangle’s  area 

equal;  Rectangle  — ^  Boolean;  %  comparison  of  rectangles  for  equality] 

{forall  r,  rl:  Rectangle,  x,  y:  Nat. 

r.defaultj-ectangle  ==  do  in-parallel  r.length  :=  0,  r.width  :=  0  enddo; 
r.create(x,  y)  ==  do  in-parallel  r.length  ;=  x,  r.width  :=  y  enddo; 
r.area  ==  r.length  *  r.width; 

r.equal(rl)  ==  r.length  =  rl.length  k  r.width  =  rl.width}; 

Note  the  specification  methodology:  each  mutator  is  defined  in  terms  of  a  transition  rule  setting  values  of 
object’s  attributes,  and  each  observer  is  defined  by  a  conventional  axiom. 

Another  version  of  Object-oriented  ASMs  permitting  late  binding  of  methods  is  described  in  [44]. 

4  Dynamic  systems  with  implicit  state 

4.1  Notion  of  dynamic  system 

The  convergence  of  the  works  on  AS-IS  and  typed  ASM  has  eventually  led  to  the  notion  of  dynamic  systems 
which  is  based  on  the  state-as-algebra  concept  and  formalizes  state  updates  as  operations  on  algebras  [20,43]. 

Let  Z"  be  a  static”  signature  introducing  a  number  of  data  types,  Seac  a  signature  of  elementary  access 
functions,  a  signature  of  dependent  access  functions,  and  Smod  a  signature  of  modifiers.  Then  a  dynamic 
system,  Z)(A),  of  signature  <  Z,  Z^ac,  Z^„  Emod  >,  where  A  is  a  Z-algebra,  is  defined  as  a  3-uple  with- 

-  carrier  \D{A)\  which  is  a  set  of  (Z  U  Zeac)-algebras  with  the  same  Z-algebra  A, 

-  some  set  of  dependent  access  functions  with  names  and  profiles  defined  in  Eac, 

-  some  set  of  defined  modifiers  with  names  and  profiles  defined  in  Emod- 

access  function  name  ac  :  si,...,s„  s  is  interpreted  in  a  dynamic  system  D{A)  by  a  map 

i5(A)-algebra  A'  (i.e.,  an  algebra  belonging  to  the  carrier  of  D(A))  a  function 
:  A',i  x  ...  x  ->  A^. 

The  operation  associated  with  a  defined  modifier  of  Emod  is  a  transformation  of  a  I>(A)-algebra  into  another 
D(A)-algebra. 


4.2  Specification  of  a  dynamic  system 
Let 

DS  <  (Z,  Ax),  {Eeac,  Axinit),  {Eac,  Axac,  Emod,  >  be  a  dynamic  system  specification.  It  has  three 

levels; 

1.  The  first  level  is  a  classical  algebraic  specification  <  Z,Aa;  >  (cf.  [12,38])  which  defines  the  data  types 
used  m  the  system.  Semantics  of  this  specification  is  given  by  the  specification  language  used.  The  approach 
is  relatively  independent  of  a  particular  specification  language.  It  is  only  required  that  the  semantics  of  a 
specification  is  a  class  of  algebras. 

2.  The  second  level  defines  those  aspects  of  the  system’s  state  which  are  likely  to  change  and  the  initial  states 
It  includes: 

-  A  signature,  E^ac,  which  does  not  introduce  new  sorts.  It  defines  the  the  names  and  profiles  of  elementary 
access  functions.  A  model  of  the  specification  <  Z  U  E^ac,  Az:  >  is  a  state.  In  the  sequel,  E'  stands  for 
Z  U  Eeac- 

-  A  set  of  axioms,  Axjnu,  characterizing  the  admissible  initial  states,  i.  e.  stating  the  initial  properties  of 
the  system. 

3.  The  third  level  defines  some  dependent  access  functions  and  possible  evolutions  of  the  system’s  states  Two 
parts  are  distinguished  here. 

-  A  specification  of  dependent  access  functions  <  EacAxac  >■  It  does  not  introduce  new  sorts  and  uses 
the  elementary  access  functions  and  the  operations  of  Z.  The  form  of  this  specification  is  the  same  as 
in  Ah-lb.  However,  the  semantics  is  different  (see  the  preceding  subsection)  in  order  to  simplify  the 
semantics  of  state  updates. 

A  Z(A)-algebra  A'  can  be  extended  into  an  algebra  A"  of  signature  Z"  =  Z'  U  Eac  satisfying  Ax 
Such  an  algebra  is  called  an  extended  state.  The  extended  state  corresponding  to  the  state  A'  is  denoted 
by  ExtE"{A  )  m  the  sequel.  Given  a  Z'-algebra  A'  and  its  extended  state  A",  any  ground  term  of  T^n 
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corresponds  to  a  value  in  A'  since  the  specification  of  A"  does  not  introduce  new  sorts  and  is  sufficiently 
complete  with  respect  to  the  specification  of  A'  (cf.  Section  2).  Thus,  the  notion  of  the  value  of  a  ground 
£'"-term  in  a  D(A)-algebra  A!  can  be  used. 

-  A  definition  of  defined  modifiers,  <  SmodfDef^^^  >.  The  form  of  this  specification  is  the  same  as  in 
Section  2. 

As  sketched  above,  a  modifier  name  mod :  si, Sn  from  Umod  is  interpreted  in  a  dynamic  system  D(A) 
by  a  map  mod^^^'>  associating  a  Z>(A)-algebra  B  with  each  pair  <  A',  <  vi,...,Vn  »,  where  A'  is 
a  D(A)-algebra  and  Vi  is  an  element  of  A^.;  this  map  must  satisfy  the  corresponding  definition  from 
Defmod  9-8  stated  in  [20]. 

This  approach  gives  a  semantics  of  modifications  themselves,  independently  of  their  applications.  More¬ 
over,  the  fact  that  the  dependent  accesses  are  no  more  part  of  the  state  makes  the  semantics  of  elementary 
updates  much  simpler  [20]. 


4.3  States  and  behaviors  of  the  system 

The  notions  of  state  and  behavior  introduced  in  Section  2  are  redefined  below  for  dynamic  systems. 

Let  DS  =  <  {B,  Ax),  (Seac,Axinit),i^ac,A.Xac,Bmod,  Defmod)  >  be  a  specification  of  a  dynamic  system, 
and  let  B'  =  BU  B^ac- 

System’s  state.  As  already  mentioned,  a  state  of  the  system,  defined  by  the  specification  DS  is  a  T'-algebra 
satisfying  the  axioms  Ax. 

It  is  important  that  each  change  of  state  preserves  the  data  types  used.  This  leads  to  the  partitioning  of 
<  B',Ax  >-algebras  into  subsets,  state a{B',  Ax),  consisting  of  algebras  sharing  the  same  interpretation  of  the 
data  types.  Since  <  B',Ax  >  is  just  an  extension  of  the  specification  <  B,  Ax  >  with  some  operation  names, 
we  have  : 

{}JstateA{B',Ax))AeAig{E,Ax)  =  Alg{B',Ax) 

Initial  states.  A  subset  of  this  set  of  models  represents  possible  initial  states  of  the  system  being  specified.  It 
corresponds  to  an  enrichment  of  the  specification  <  B',  Ax  >  with  Axjnit  ,  thus; 
stateinitiDS)  =  {A'  G  Alg{B',Ax  >)|A'  j=  Axjnit) 

Behavior  of  the  system.  A  behavior  is  a  sequence  of  updates  which  are  produced  by  the  invocations  of 
some  modifiers.  Several  sequences  of  states  (eo,ei,e2, ...)  correspond  to  a  behavior  {mo,mi,rn2,  ■■■)  depending 
on  the  choice  of  the  initial  state; 

-  the  initial  state  Cq  belongs  to  state jnit{DS)  ; 

-  each  ej+i  is  the  result  of  the  application  of  the  modifier  to  e,  (6*41  =  |m|ei)  . 

The  semantics  of  updates  as  it  is  defined  in  [20]  guarantees  that  if  eo  belongs  to  a  dynamic  system  D{A),  then 
any  Cj  also  belongs  to  D{A)  (the  state  changes,  but  the  data  type's  do  not  change). 

As  AS-IS,  this  formalism  is  deterministic  for  two  reasons;  the  semantics  of  elementary  modifiers  and,  there¬ 
fore,  of  all  modifiers  ensures  that  one^  and  only  one  state  (up  to  isomorphism)  is  associated  with  the  application 
of  a  modifier  to  a  state;  besides  the  specification  of  dependent  access  functions,  <  Bac,Axac  >,  is  sufficiently 
complete  with  respect  to  <  BUBeac,  Ax  >.  Thus,  only  one  sequence  of  states  starting  with  a  given  initial  state 
is  associated  with  a  behavior. 

Reachable  states.  The  set  of  reachable  states,  REACH  (DS)  is  the  set  of  states  which  can  be  obtained 
by  a  sequence  of  updates  corresponding  to  the  invocations  of  some  modifiers  of  Bmodi  starting  from  an  initial 
state. 

Thus,  the  set  REACH{DS)  is  recursively  defined  in  the  following  way; 

-  stateinitiDS)  C  REACH{DS) 

-  Vm  G  Bmod,  Vti  G  (rs»)»i  iTE^’)s^,  VA'  G  REACHiDS), 

lmiti,...,tn)'lA'  e  REACH{DS). 

^  provided  that  the  validity /in  validity  of  the  conditions  in  conditional  updates  is  always  defined 
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5  Related  works 


One  of  the  first  specification  languages  with  states  represented  by  algebras  is  COLD-K  [18],  the  kernel  lan¬ 
guage  of  the  COLD  family  of  specification  languages.  It  possesses  many  of  the  features  mentioned  above,  e.g. 
dynamic  (elementary  access)  functions,  dependent  (access)  functions  and  procedures  (modifiers).  Procedures 
are  considered  as  relations  on  states.  For  the  specification  purposes  some  imperative  constructions  (sequential 
composition  expressions  and  repetition  expressions)  are  used.  However,  it  is  still  mainly  axiomatic  specification 
language  using  pre-  and  post-conditions  resembling  those  of  VDM. 

The  idea  of  implicit  state  in  terms  of  a  new  mathematical  structure,  d-oid,  is  given  by  Astesiano  and  Zucca 
[2].  A  d-oid,  like  the  dynamic  system  described  above,  is  a  set  of  algebras  (states)  called  instant  structures,  set  of 
dynamic  operations  (transformations  of  instant  structures  with  a  possible  result  of  a  definite  sort)  and  a  tracking 
map  indicating  relationships  between  instant  structures.  Dynamic  operations  in  a  d-oid  serve  as  counterparts 
of  dependent  access  functions  and  modifiers  in  AS-IS  and  the  tracking  map  provides  a  very  abstract  way  of 
identifying  components  of  different  instant  structures  (there  is  no  notion  of  tracking  map  in  the  above  definition 
of  dynamic  systern  since  each  algebra  of  the  same  signature  is  by  definition  a  mapping  of  the  same  set  of  names 
to  a  semantics  universe).  The  approach  in  question  deals  only  with  models  and  does  not  address  the  issue  of 
specifying  the  class  of  such  behaviors,  which  is  the  purpose  of  imperative  specifications. 

Dynamic  types  as  a  modified  version  of  d-oid  are  further  investigated  in  [45].  Although  no  direct  definition 
of  a  dynamic  abstract  type  is  given  in  that  paper,  it  has  contributed  by  formal  definitions  of  a  static  framework 
and  of  a  dynamic  framework  with  a  corresponding  logical  formalism  over  a  given  static  framework.  It  seems 
that  the  formalism  can  be  used  as  a  basis  of  an  imperative  specification  language. 

Another  similar  approach  is  the  “Concurrent  State  Transformation  on  Abstract  Data  Types”  presented  in 
[23].  It  also  uses  the  idea  of  implicit  state  which  is  modeled  as  partial  algebra  that  extends  a  fixed  partial  algebra 
considered  as  a  static  data  type.  All  functions  are  given  at  the  same  level.  Dynamic  functions  are  considered 
totally  undefined  in  the  static  data  type.  A  state  on  a  given  partial  algebra  is  a  free  extension  of  this  algebra, 
specified  by  a  set  of  function  entries.  Invariant  relations  between  dynamic  operations  are  given  by  axioms  at  the 
static  level.  Transitions  between  states  are  specified  by  conditional  replacement  rules  indicating  the  function 
entries  that  should  be  added/removed  when  the  condition  is  valid. 

There  are  some  restrictions  on  the  partial  equational  specifications  for  the  static  data  types,  the  admissible 
partial  algebras  and  states,  and  the  replacement  rules  in  order  to  have  the  same  structural  properties  as  the 
algebraic  specification  logic.  The  most  severe  of  them  is  the  restriction  of  replacement  rules  only  to  redefinitions 
of  so  called  contents  functions  corresponding  to  the  mappings  of  variables  to  their  values  in  programming 
languages.  This  leads  to  severe  restrictions  on  the  use  of  the  formalism  (one  cannot  define  and  update  an 
arbitrary  dynamic  function). 

In  a  slightly  revised  form  the  formalism  is  used  in  [24]  for  the  definition  of  algebra  transformation  systems 
and  their  compositions. 

updating  operations  are  interpreted  as  relations  between  algebras  in  [3],  and  these  relations  are 
specified  by  the  usual  algebraic  specification  technique.  To  make  the  difference  between  the  original  and  updated 
values  of  the  same  function  (constant),  one  has  to  decorate  its  name  in  a  formula.  This  leads  to  the  necessity  of 
having  t^wo  signatures  (one  for  the  original  algebra  and  one  for  the  resulting  algebra)  and  signature  morphisms 
for  establishing  the  correspondence  between  decorated  and  non-decorated  versions  of  the  same  name  and  writing 
formulae  in  the  discriminated  union  of  the  signatures.  fYom  some  examp;es  of  the  paper,  it  seems  that  this  can 
lead  to  rather  complex  specifications. 

Finally,  the  specification  language  Troll  [30]  should  be  mentioned.  It  is  oriented  on  the  specification  of  static 
and  dynamic  properties  of  objects  where  a  method  (event)  is  specified  by  means  of  evaluation  rules  resembling 
equations  on  attribute  values.  Although  the  semantics  of  TVoll  is  given  rather  informally,  there  is  a  strong 
mathematical  foundation  of  its  dialect,  lYoll  light  [21],  with  the  use  of  data  algebras,  attribute  algebras  and 
event  algebras.  An  attribute  ^gebra  represents  a  state.  A  relation  constructed  on  two  sets  of  attribute  algebras 
and  a  set  of  event  algebra,  called  object  community,  formalizes  a  transition  from  one  attribute  algebra  to  another 
when  a  particular  event  algebra  takes  place. 


6  Conclusion 

This  survey  paper  provides  a  guided  tour  of  several  imperative  approaches  of  specification  based  on  the  state- 

systems  w7h 
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Some  of  these  approaches  differ  in  significant  way.  This  is  an  indication  of  the  generality  of  the  paradigm.  In 
AS-IS,  the  aim  is  to  specify  the  dynamic  evolutions  of  the  specified  systems  in  a  high  level  and  non  algorithmic 
way.  In  ASM,  the  goal  is  to  provide  a  way  of  describing  algorithms  in  an  abstract  way.  Moreover,  the  problem 
of  multiple  inconsistent  updates  is  considered  very  differently  in  both  approaches,  as  mentioned  in  Section  3.1. 

One  of  the  advantages  of  these  approaches  to  formal  specification  is  a  better  understandability  for  people 
familiar  with  imperative  programming.  AIS  use  a  simple  syntax  which  can  be  read  as  a  form  of  high  level  code. 

Another  advantage  is  their  generality.  AIS  have  been  shown  to  be  useful  in  such  wide  variety  of  domains  as 
sequential,  parallel  and  distributed  systems  with  either  finite-state  or  infinite  domains. 

A  current  weakness  of  these  approaches  is  the  lack  of  formal  calculus  to  perform  proofs.  It  is  very  likely  that 
a  calculus  based  on  the  concept  of  substitution,  in  the  line  of  Abrial’s  calculus  for  B  [1]  could  be  developed.  It 
is  the  subject  of  some  future  work. 
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Abstract.  A  semi-visual  framework  for  the  specification  of  syntax  and  semantics  of  imperative  program¬ 
ming  languages,  called  Montages,  was  proposed  in  an  earlier  work  by  the  authors.  The  primary  aim  of 
this  formalism  is  to  assist  in  recording  the  decisions  taken  by  the  designer  during  the  language  design 
process.  The  associated  tool  Gem-Mex  allows  the  designer  to  maintain  the  specification  and  to  inspect  the 
semantics  to  verify  whether  the  design  decisions  have  been  properly  formalized. 

Experience  with  full-scale  case  studies  on  Oberon,  Java,  and  domain  specific  languages  showed  the  close  re¬ 
lationship  to  Finite  State  Machines  (FSMs).  This  paper  gives  a  new  definition  of  Montages  based  on  FSMs. 
It  confers  to  the  formalism  enhanced  pragmatic  qualities,  such  as  writability,  extensibility,  readability,  and, 
in  general,  ease  of  maintenance. 


1  Introduction 

The  aim  of  Montages  is  to  document  formally  the  decisions  taken  during  the  design  process  of  realistic  program¬ 
ming  languages.  Syntax,  static  and  dynamic  semantics  are  given  in  a  uniform  and  coherent  way  by  means  of 
semi-visual  descriptions.  The  static  aspects  of  a  language  are  diagrammatic  descriptions  of  control  flow  graphs, 
and  the  overall  specifications  are  similar  in  structure,  length,  and  complexity  to  those  found  in  common  language 
manuals. 

The  departure  point  for  our  work  has  been  the  formal  specification  of  the  C  language  [10]^,  which  showed 
how  the  state-based  formalism  Abstract  State  Machines  [8,9,13]  (ASMs),  formerly  calldd  Evolving  Algebras, 
is  well-suited  for  the  formal  description  of  the  dynamic  behavior  of  full-blown  practical  languages.  In  essence, 
ASMs  constitute  a  formalism  in  which  a  state  is  updated  in  discrete  time  steps.  Unlike  most  state-based  systems, 
the  state  is  given  by  an  algebra,  that  is,  a  collection  of  functions  and  universes.  The  state  transitions  are  given 
by  rules  that  update  functions  pointwise  and  extend  universes  with  new  elements.  The  model  presented  in  [10] 
describes  the  dynamic  semantics  of  the  C  language  by  presuming  on  an  explicit  representation  of  control  and 
data  flow  as  a  graph.  This  represents  a  major  limitation  for  such  a  model,  since  the  control  and  data  flow  graph 
is  a  crucial  part  of  the  specification.  Therefore,  we  developed  Montages  which  extend  the  approach  in  [10]  by 
introducing  a  mapping  which  describes  how  to  obtain  the  control  and  data  flow  graph  starting  from  the  abstract 
syntax  tree. 

The  formulation  of  Montages  [17]  was  strongly  influenced  by  some  case  studies  [16, 18]  where  the  object- 
oriented  language  Oberon  [26]  has  been  specified.  Montages  have  been  used  also  in  other  case  studies,  such 
as  the  specification  of  the  Java  [25]  language,  the  front-end  for  correct  compiler  construction  [11],  and  the 
design  and  prototyping  of  a  domain-specific  languages  in  an  industrial  context  [19].  The  experience  showed 
that  the  underlying  model  for  the  dynamic  semantics,  namely  the  specification  of  a  control  flow  graph  including 
conditional  control  flow  and  data  flow  arrows  and  its  close  relationship  to  the  well  known  concept  of  Finite  State 
Machines,  shortens  the  learning  curve  considerably.  In  this  paper  a  new  FSM  based  definition  of  Montages  is 
given.  Complete  references,  documentation  and  tools  can  be  obtained  via  [4]. 

2  Montages 

In  our  formalism,  the  specification  of  a  language  consists  of  several  components.  As  depicted  in  Fig.  1,  the 
language  specification  is  partitioned  into  three  parts. 

^  Historically  the  C  case-study  was  preceded  by  work  on  Pascal  [8],  and  other  languages,  see  [5]  for  a  commented 
bibliography  on  ASM  case  studies. 
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Fig.  1.  Relationship  between  language  specification  and  instances. 


1.  The  EBNF  production  rules  are  used  for  the  context-free  syntax  of  the  specified  language  L,  and  they  allow 
to  generate  a  parser  for  programs  of  L.  Furthermore,  the  rules  define  in  a  canonical  way  the  signature  of 
abstract  syntax  trees  (ASTs)  and  how  the  parsed  programs  are  mapped  into  an  AST.  Section  2.1  contains 
the  details  of  this  mapping.  In  Fig.  1  the  dotted  arrow  from  the  EBNF  rules  visualizes  that  this  information 
is  provided  from  the  Montage  language  specification. 

2.  The  next  part  of  the  specification  is  given  using  the  Montage  Visual  Language  (MVL).  MVL  has  been 
explicitly  devised  to  extend  EBNF  rules  to  finite  state  machines  (FSM).  A  MVL  description  associated 
to  an  EBNF  rule  defines  basically  a  local  finite  state  machine  and  contains  information  how  this  FSM  is 
plugged  into  the  global  FSM  via  an  inductive  decoration  of  the  abstract  syntax  trees.  To  this  end,  each 
node  is  decorated  with  a  copy  of  the  finite  state  machine  fragment  given  by  its  Montage.  The  reference  to 
descendents  m  the  AST  defines  an  inductive  construction  of  a  global  structured  FSM.  In  Section  2.2  we 
define  how  this  construction  works  exactly. 

3.  Finally,  any  node  in  the  FSM  may  be  associated  with  an  Abstract  State  Machine  (ASM)  rule  This  action 
rule  IS  fired  when  the  node  becomes  the  current  state  of  the  FSM.  As  shown  in  Fig.  1,  the  specification  of 
these  rules  is  the  third  part  of  a  Montages  specification. 


•  language  specification  is  structured  in  specification  modules,  called  Montages.  Each  Montage 

context-free  grammar  rule  (by  means  of 
EBNF),  the  (locaji  finite  state  machine  (by  means  of  MVL),  and  the  dynamic  semantics  of  the  construct  (by 
means  of  ASMs).  The  special  form  of  EBNF  rules  allowed  in  a  specification  and  the  definition  of  Montages  lead 
to  the  fact  that  each  node  in  the  abstract  syntax  tree  belongs  exactly  to  one  Montage. 

As  an  example  the  Montage  for  a  nonterminal  with  name  Sum  is  shown  in  Fig.  2.  The  topmost  parts  of  this 
Montages  is  the  production  rule  defining  the  context-free  syntax.  The  remaining  part  defines  static  aspects  of 
the  construct  given  by  means  of  an  MVL  description.  Additionally,  the  Montage  contains  an  action  rule,  which 
IS  evaluated  after  the  two  operands,  i.e.  when  the  control  reaches  the  sum  node. 

The  defimtion  of  Montages  usuahy  contains  a  fourth  section  which  is  devoted  to  the  specification  of  static 
analysis  and  semantics.  After  working  with  fixed  traversal  orders  and  non-local  attributions,  we  found  that 
Reference  Attribute  Grammars  [12]  are  most  suited  for  our  purpose.  They  allow  us  to  abstract  from  the  traversal 
order  while  not  restricting  the  use  of  non-local  references.  The  result  of  the  attribution  can  be  used  to  define 
firing  conditions  in  the  global  FSM. 

_  The  combination  of  attribute  grammars  for  static  analysis  and  semantics  is  standard  technique.  In  [I2l  it 
IS  shown  how  reference  attribute  grammars  define  static  properties  of  an  object  oriented  languages  in  a  simple 
Md  concise  way.  Further  [22]  uses  a  corresponding  functional  system  in  combination  with  ASMs  and  shows 
ow  to  describe  static  and  dynamic  aspects  of  full-blown  languages.  In  contrast  to  these  works.  Montages  has 
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Fig.  2.  Montage  components. 


an  elaborated  visual  formalism  for  the  specification  of  sequential  control  flow  by  means  of  FSMs.  These  aspects 
are  going  to  be  presented  in  the  next  sections. 

2.1  From  Syntax  to  AST 

In  this  section,  the  first  step  in  Fig.  1  is  described.  As  a  result  of  this  step  we  get  the  abstract  syntax  tree  of  the 

specified  program.  But  we  also  compose  the  Montages  corresponding  to  the  different  constructs  of  the  language. 

This  composition  of  the  partial  specifications  is  done  based  on  the  structure  of  the  AST. 

EBNF  rules  The  syntax  of  the  specified  language  is  given  by  the  collection  of  all  EBNF  rules.  Without  loss 
of  generality,  we  assume  that  the  rules  are  given  in  one  of  the  two  following  forms: 

A -.—  BCD  (1) 

E  =  F\G\H  (2) 

The  first  form  defines  that  A  has  the  components  B,C,  and  D  whereas  the  second  form  defines  that  E  is  one 
of  the  alternatives  F,  G,  or  H.  Rules  of  the  first  form  are  called  characteristic  productions  and  rules  of  the 
second  form  are  called  synonym  productions.  We  guarantee  that  each  non-terminal  symbol  appears  in  exactly 
one  rule  as  the  left-hand-side.  Non-terminal  symbols  appearing  on  the  left  of  the  first  form  of  rules  are  called 
characteristic  symbols  and  those  appearing  on  the  left  of  synonym  productions  are  called  synonym  symbols. 

Composition  of  Montages  Each  characteristic  symbol  and  certain  terminal  symbols  define  a  Montage.  A 
Montage  is  considered  to  be  a  class^  whose  instances  are  associated  to  the  corresponding  nodes  in  the  abstract 
syntax  tree.  Symbols  in  the  right-hand  side  of  a  characteristic  EBNF  rule  are  called  (direct)  components  of 
the  Montage,  and  symbols  which  are  reachable  as  components  of  components  are  called  indirect  components. 
In  order  to  access  descendants  of  a  given  node  in  the  abstract  syntax  tree,  statically  defined  attributes  are 
provided.  Such  attributes  are  called  selectors  and  they  are  unambiguously  defined  by  the  EBNF  rule.  In  the 
above  given  rule,  the  B,  C,  and  D  components  of  an  A  instance  can  be  retrieved  by  the  selectors  S-B,  S-C,  and 
S-D.  In  Fig.  3  a  possible- representation  of  the  A-Montage  as  class  and  2Ln  abstract  syntax  tree  (AST)  with  two 
instances  of  A  and  their  components  are  depicted. 

Synonym  rules  introduce  synonym  classes  and  define  subtype  relations.  The  symbols  on  the  right-hand-side 
of  a  synonym  rule  can  be  further  synonym  classes  or  Montage  classes.  Each  class  on  the  right-hand-side  is  a 
subtype  of  the  introduced  synonym  class.  Thus,  each  instance  of  one  of  the  classes  on  the  right-hand  side  is  an 
instance  of  the  synonym  class  on  the  left-hand-side,  e.g.  in  the  given  example,  all  F-,  G-,  and  H-instances  are 
E-instances  as  well.  In  the  AST,  each  inner  node  is  an  an  instance  of  arbitrarily  many  (possibly  zero)  synonym 
classes  and  of  exactly  one  Montage. 

Terminals,  e.g.  identifiers  or  numbers,  do  not  correspond  to  Montages.  The  micro-syntax  can  be  accessed 
using  an  attribute  Name  from  the  corresponding  leaf  node.  The  described  treatment  of  characteristic  and 
synonym  productions  allows  for  an  automatic  generation  of  AST  from  the  concrete  syntax  given  by  EBNF,  see 
also  the  work  in  [21]. 

^  In  this  context  we  consider  class  to  be  a  special  kind  of  abstract  data  type,  having  attributes  and  methods  (actions) 
and,  most  important  for  us,  where  the  notion  of  sub-typing  and  inheritance  are  predefined  in  the  usual  way. 
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Induced  structures  Inside  a  Montage  class,  the  term  self  denotes  the  current  instance  of  the  class.  Using  the 
selectors,  and  knowledge  about  the  AST,  we  can  build  paths  w.r.t.  to  self.  For  instance,  the  path  self.S-B.S- 
H.S-J  denotes  a  node  of  class  J,  which  can  be  reached  by  following  the  selectors  S-B,  S-H,  and  then  S-J,  see  Fig. 
4.  The  use  of  such  a  path  in  a  Montage  definition  imposes  a  number  of  constraints  on  the  other  EBNF  rules  of 
the  language.  The  example  self. S-B. S-H. S-J  requires  that  there  is  a  B  component  in  the  Montage  containing 
the  path.  Further,  every  subtype  of  B  must  have  an  H  component,  and  every  subtype  of  H  must  have  an  J 
component.  In  other  words,  the  path  self.S-B.S-H.S-J  must  exist  in  all  possible  ASTs. 


Exan^le  As  a  running  example  we  give  a  small  language  S.  The  expressions  in  this  language  potentially  have 
side  effects  and  must  be  evaluated  from  left  to  right.  The  atomic  factors  are  integer  constants  and  variables  of 
type  integer.  The  start  symbol  of  the  EBNF  is  Expr,  and  the  remaining  rules  are 


Expr 

Sum 

Factor 

Variable 

Constant 


=  Sum  I  Factor 
:;=  Factor  Expr 

=  Variable  ]  Constant 

Ident 
Digits 


The  following  terra  is  an  5-program: 


2  +  X  +  1 


As  a  result  of  the  generation  of  the  AST  we  obtain  the  structure  represented  in  Fig.  5.  In  particular  the 
nodes  from  1  to  8  represent  instances  of  the  Montage  classes  and  the  edges  point  to  the  successors  of  a  particular 
node.  The  edges  are  labeled  with  the  selector  functions  which  can  be  used  in  the  Montage  corresponding  to 
the  source  node  to  access  the  Montage  corresponding  to  the  target  node.  The  nodes  themselves  show  the  class 
hierarchy  starting  from  the  synonym  class  and  ending  with  the  Montage  class.  The  leaf  nodes  contain  the 
definition  of  the  attribute  Name,  i.e.  the  micro-syntax. 


2.2  Prom  AST  to  Control  Flow  Graphs 

According  to  Fig.  1,  the  next  step  in  building  the  data  structure  for  the  dynamic  execution  is  the  inductive 
decoration  of  the  AST  with  a  number  of  finite  state  machines.  Again,  this  process  is  described  rather  informally 
here. 

As  we  have  seen  in  Fig.  2,  the  second  part  of  a  Montage  contains  the  necessary  specifications  given  in  form 
of  the  Montage  Visual  Language  (MVL).  The  Montages  for  the  productions  Variable  and  Constant  are  given  in 
Fig  6.  Two  kinds  of  information  are  represented  in  the  second  part  of  a  Montage:  (a)  the  local  state  machine 
to  be  associated  to  the  node  of  the  AST  and  (b)  information  on  the  embedding  of  this  local  state  machine 
Using  our  running  example.  Fig.  7  just  represents  the  MVL  sections  of  the  Montages  as  they  are  associated  to 
the  corresponding  nodes  of  the  abstract  syntax  tree.  The  hierarchical  state  transition  graph  resulting  from  the 
inductive  decoration  is  shown  in  Fig.  8  for  the  running  example. 


Fig.  3.  Montage  class  A,  instances  in  the  AST,  selectors  S-B,  S-C,  S-D 
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Montage  Visual  Lain.guage  Now,  the  elements  of  the  MVL  and  their  semantics  can  be  described  as  follows: 

-  There  are  two  kinds  of  nodes.  The  oval  nodes  represent  states  in  the  generated  finite  state  machine.  These 
states  are  associated  to  the  AST  node  corresponding  to  the  Montages.  The  oval  nodes  are  labeled  with  an 
attribute.  It  serves  to  identify  the  state,  for  example  if  it  is  the  target  of  a  state  transition  or  if  it  points  to 
a  dynamic  action  rule. 

-  The  rectangular  nodes  or  boxes  represent  symbols  in  the  right  hand  side  of  the  EBNF  rule  and  are  called 
direct  components  of  a  Montages,  see  Section  2.1.  They  are  labeled  with  the  corresponding  selector  function. 
Boxes  may  contain  other  boxes  which  represent  indirect  components.  This  way,  paths  in  the  AST  are 
represented  graphically. 

-  The  dotted  arrows  are  called  control  arrows.  They  correspond  to  edges  in  the  hierarchical  state  transition 
graph  of  the  generated  finite  state  machine.  Their  source  or  target  can  be  any  box  or  oval.  In  addition,  their 
source  or  target  can  be  either  the  symbol  I  {I  stands  for  initial)  or  T  {T  stands  for  terminal),  respectively. 
In  a  Montage,  at  most  one  symbol  of  each,  I  and  T,  is  allowed.  If  the  /  symbol  is  omitted,  the  states  of  the 
Montage  can  only  be  reached  using  a  jump,  if  the  T  symbol  is  omitted,  the  Montages  can  only  be  left  using 
a  jump. 

-  As  in  other  state  machine  formalisms  (such  as  Harel’s  StateCharts),  predicates  can  be  associated  to  control 
arrows.  They  are  simply  terms  in  the  underlying  ASM  formalism  and  are  evaluated  after  executing  the 
action  rule  associated  to  the  source  node.  Predicates  must  not  be  associated  to  control  arrows  with  source 
I. 

-  There  are  additional  notations  not  used  in  this  paper  —  for  example  data  flow  edges  representing  the  mutual 
access  of  data  between  Montages  and  box  structures  representing  lists  in  an  effective  way.  Moreover,  in  this 
section  of  a  Montage,  one  may  specify  further  action  rules  to  be  performed  in  the  static  analysis  phase,  for 
example  building  up  data  structures  necessary  for  the  static  and  dynamic  semantics. 

It  remains  to  show  how  the  hierarchical  finite  state  machine,  for  example  Fig.  8  is  built  and  how  its  dynamic 
semantic  is  defined. 

Hierarchical  FSM  Building  the  hierarchical  FSM  is  particularly  simple.  The  boxes  in  the  MVL  are  references 
to  the  corresponding  local  state  transition  graphs.  Remember  that  nested  boxes  correspond  to  paths  in  the 
AST.  Therefore,  there  are  references  to  children  only,  i.e.  to  other  state  transition  graphs  along  the  edges  of  the 
AST.  After  resolving  the  references,  a  representation  as  in  Fig.  8  is  obtained. 

Dynamic  Semantics  After  the  static  analysis  phase  action  rules  are  executed  which  define  the  dynamic 
semantics  of  the  leuiguage. 

-  States  of  the  finite  state  machines  are  visited  sequentially. 

-  The  action  rule  associated  to  a  visited  state  is  executed.  The  specification  of  these  actions  is  based  on  the 
ASM  formalism 

-  The  control  is  passed  to  the  next  state  along  a  control  arrow  whose  predicate  evaluates  to  true.  The  control 
predicate,  i.e.  a  term  in  the  ASM  formalism,  is  evaluated  after  executing  the  action  associated  to  the  source 
node. 

If  there  is  more  than  one  possible  next  state,  the  system  behaves  like  a  nondeterministic  FSM.  Up  to  now 
we  did  not  use  nondeterministic  FSMs. 


Pig.  4.  Montage  A  using  path  self.S-B.S-H.S-J,  situation  in  AST,  and  constraints  on  EBNF  rules  of  B,  H. 
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Fig.  5.  The  abstract  syntax  tree  and  composition  of  Montages  for  2  +  x  +  1 


If  the  target  of  a  control  arrow  is  a  T,  then  a  control  arrow  leaving  the  corresponding  box  in  the  enclosing 
parent  state  machine  is  followed.  The  term  parent  refers  to  the  partial  ordering  of  local  state  machines  as 
imposed  by  the  AST. 

—  If  the  target  of  a  control  arrow  is  a  box,  the  corresponding  local  state  machine  corresponding  to  it  is  entered 
via  the  symbol  I. 

More  formally,  the  arrows  from  I  and  to  the  T  symbols  define  two  unary  functions,  Initial  and  Terminal 
denoting  for  each  node  in  the  AST  the  first,  respectively  last  state  that  is  visited.  According  to  the  above 
description,  the  inductive  definition  of  these  functions  is  given  as  follows. 

For  each  state  s  in  the  finite  state  machines, 

s.Initial  —  s  (3^ 

s.  Terminal  =  s  ^4^ 

and  for  each  instance  n  of  a  Montage  N  whose  MVL-graph  has  an  edge  from  /  to  a  component  denoted  by  path 


n. Initial  —  n.tgt. Initial 

and  for  each  instance  m  of  a  Montage  M  whose  MVL-graph  has  an  edge  from  a  component  denoted  by  path 
src  to  T, 

m. Terminal  —  m.src. Terminal 

Using  these  definitions,  the  structured  finite  state  machine  can  be  flattened.  The  arrows  of  the  fiat  finite 
state  machine  are  given  by  the  following  equations  defining  the  relation  ControlArrow.  For  each  instance  n  of  a 
Montage  N  and  each  edge  e  in  the  MVL-graph  of  N, 

ControlArrow{n.src.Terminal,n.tgt.Initial))  =  true 


Variable  ::=  Ident 

Constant  Digits 

I — lookup  - >.X 

I-  set  Value^]^ — 

©lookup: 
value  := 

CurrentStore( S-Ident.Name ) 

©setValue: 

value  :=  S-Digits.Name 

Fig.  6.  The  Montages  for  the  language  S. 
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Fig.  7.  The  finite  state  machines  belonging  to  the  nodes. 


Fig.  8.  The  constructed  hierarchical  finite  state  machine. 


w’here  src  is  the  path  of  the  source  of  e  and  tgt  is  the  path  of  the  target  of  e. 

Applying  these  definitions  to  the  running  example  results  in  the  fiat  state  machine  of  Fig.  9.  In  the  same 
figure  the  dotted  lines  denote  the  relation  of  a  state  to  its  corresponding  Montage,  which  is  accessible  as  self. 
Using  the  Montages  shown  in  Figs.  2  and  6  and  their  action  rules,  we  can  track  how  the  ASM  rule  associated 
with  the  add  states  can  access  the  AST-nodes  of  its  left  and  right  arguments  as  self.S-Factor  and  self.S-Expr. 
The  results  of  calculations  performed  by  the  actions  are  stored  in  the  additional  attributes  value.  The  add  action 
accesses  the  values  of  its  arguments  using  the  selectors,  and  defines  its  own  value  field  to  be  the  sum  of  the 
arguments.  Assuming  that  CurrentStore  maps  x  to  4,  the  execution  of  the  flat  or  structured  finite  state  machine 
sets  the  value  of  node  two  to  the  constant  2,  sets  the  value"  of  node  five  to  the  current  store  at  x,  sets  the  value 
of  node  six  to  1,  sets  the  value  of  node  three  to  the  sum  of  4  and  1,  and  finally  sets  the  value  of  node  one  to 
the  sum  of  2  and  5. 

3  Gem-Mex:  The  Development  Environment  for  Montages 

The  development  environment  for  Montages  is  given  by  the  Gem-Mex  tool  [2,3].  The  intended  use  of  the  tool 
Gem-Mex  is,  on  one  hand  to  allow  the  designer  to  ‘debug’  her/his  semantics  descriptions  by  empirical  testing 
of  whether  the  intended  decisions  have  been  properly  formalized;  bn  the  other  hand,  to  automatically  generate 
a  correct  (prototype)  implementation  of  programming  languages  from  the  description,  including  visualization 
and  debugging  facilities. 

Gem-Mex  is  a  system  which  assists  the  designer  in  a  number  of  activities  related  with  the  language  life  cycle, 
from  early  design  to  routine  programmer  usage.  It  consists  of  a  number  of  interconnected  components 

-  a  specialized' graphical  editor  allows  to  enter  and  manipulate  Montages  in  a  convenient  way; 

-  frames  for  the  documentation  of  the  specified  languages  are  generated  automatically; 

-  the  Montages  executable  generator  (Mex)  generates  a  correct  and  efficient  interpreter  of  the  language; 

-  the  generic  animation  and  debugger  tool  visualizes  the  static  and  dynamic  behavior  of  the  specified  language 
at  a  symbolic  level;  source  programs  written  in  the  specified  language  and  user-defined  data  structures  can 
be  animated  and  inspected  in  a  visual  environment. 

3.1  Generation  of  Language  Interpreters 

Using  the  formal  semantics  description  given  by  the  set  of  Montages  and  a  number  of  ADTs,  the  Gem-Mex 
system  generates  an  interpreter  for  the  specified  language.  The  core  of  the  Gem-Mex  system  is  Aslan  [1],  which 
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stands  for  >lbstract  5tate  Machine  Langiia.ge  and  provides  a  fully-fledged  implementation  of  the  ASM  approach. 
Aslan  can  also  be  used  as  a  stand-alone,  general  purpose  ASM  implementation.  The  process  of  generating  an 
executable  interpreter  consists  of  two  phases: 

-  The  Montages  containing  the  language  definition  are  transformed  to  an  intermediate  format  and  then 
translated  to  an  ASM  formalization  according  to  the  rules  presented  in  the  previous  Sections. 

-  The  resulting  ASM  formalization  is  processed  by  the  Aslan  compiler  generating  an  executable  version  of 

the  formalization,  which  represents  an  interpreter  implementing  the  formal  semantics  description  of  the 
specified  language. 

Usmg  Aslan  as  the  core  of  the  Gem-Mex  system  provides  the  user  the  possibility  to  exploit  the  full  power  of 
the  ASM  framework  to  enrich  the  graphical  ASM  macros  provided  by  Montages  with  additional  formalization 


3.2  Generation  of  Visual  Programming  Environments 

Besides  pure  language  interpreters,  the  Gem-Mex  system  is  able  to  generate  visual  programming  environments 
for  the  generated  ASM  formalization  of  the  programming  language  semantics^.  This  is  done  by  providing  a 
generic  debugging  and  animation  component  which  can  be  accessed  by  the  generated  executable.  During  the 
translation  process  of  the  Montages/ ASM  code  special  instructions  are  inserted  that  provide  the  information 
being  necessary  to  visualize  the  execution  of  the  formalization.  In  particular,  the  visual  environment  can  be  used 
o  debug  the  specification,  animate  the  execution  of  it,  and  generate  documents  representing  snapshots  of  the 
visualization  of  data  structures  during  the  execution.  The  debugging  features  include  stepwise  execution,  textual 
representation  of  ASM  data  structures,  definition  of  break  points,  interactive  term  evaluation,  and  re-play  of 

<aYPfii+ir\nc  ’  ^  J 


3.3  Library  of  Programming  Language  Features 

A  concept  for  providing  libraries  of  programming  language  features  is  currently  under  development.  With  this 
concept  IS  shall  be  possible,  to  reuse  features  of  programming  languages  that  have  already  been  specified  in 
other  Montages.  Examples  for  this  kind  of  features  are  arithmetic  expressions,  recursive  function  call,  exception 
handling,  parameter  passing  techniques,  standard  control  features  etc.  The  designer  of  a  new  language  can  then 
import  such  a  feature  and  customize  it  according  to  his  or  her  needs.  The  customization  may  range  from  the 
substitution  of  keywords  up  to  the  selection  among  a  set  of  variants  for  a  certain  feature,  like  different  kinds  of 
inheritance  in  object-oriented  languages,  for  example.  In  the  Verifix  project  [11],  a  number  of  reusable  Montages 

has  been  defined  with  the  intention  to  reuse  not  only  the  Montages  but  as  well  an  associated  construction  scheme 
tor  correct  compilers. 

This  feature  is  again  available  to  all  kind  of  ASM  formalizations  implemented  in  Aslan  not  only  to  those  generated 
from  a  Montages  language  specification  seneiaLca 
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4  Related  Work 

Denotational  semantics  has  been  regarded  as  the  most  promising  approach  for  the  semantic  description  of 
programming  languages.  But  its  problems  with  the  pragmatics  have  been  discovered  already  in  case  studies 
of  the  scale  of  Pascal  and  C  [23].  Moreover  domain  definitions  often  need  to  be  changed  when  extending  the 
language  with  unforeseen  constructs,  for  instance  a  change  from  the  direct  style  to  the  continuation  style  when 
adding  gotos  [20]. 

Other  well  known  meta-languages  for  specifying  languages  are  Natural  Semantics  [14],  ASF+SDF  [24],  and 
Action  Semantics  [20].  For  somebody  knowing  mathematical  logic,  Natural  Semantics  are  pretty  intuitive  and 
we  used  it  for  the  dynamic  semantics  of  Oberon  [15].  Although  we  succeeded  due  to  the  excellent  tool  support 
by  Centaur  [7],  the  result  was  much  longer  and  more  complex  then  the  Montages  counterpart  given  in  [18], 
since  one  has  to  carry  around  all  the  state  information  in  the  case  of  Natural  Semantics.  Similar  problems  exist 
if  ASF+SDF  is  applied  to  imperative  languages.  Action  Semantics  solves  these  problems  by  providing  standard 
solutions  to  the  main  concepts  used  in  programming  languages.  Unfortunately  the  set  of  standard  solutions  is 
not  easily  extendible. 

Using  ASMs  for  dynamic  semantics,  the  work  in  [22]  defines  a  framework  comparable  to  ours.  For  the  static 
part,  it  proposes  occurrence  algebras  which  integrate  term  algebras  and  context  free  grammars  by  providing 
terms  for  all  nodes  of  all  possible  derivation  trees.  This  allows  such  an  approach  to  define  all  static  aspects  of 
the  language  in  a  functional  algebraic  system.  Since  reference  attribute  grammars  [12]  correspond  to  occurrence 
algebras  the  static  aspects  of  our  formalisms  are  almost  identical  to  those  in  [22]. 

None  of  the  discussed  approaches  uses  visual  descriptions  of  control  flow  and  none  of  them  supports  struc¬ 
turing  of  all  specification  aspects  in  a  vertical  way,  e.g.  in  self-contained  modules  for  each  language  construct. 
This  way  of  structuring  is  novel  with  respect  to  existing  frameworks,  as  far  as  we  know.  In  combination  with 
refinements  of  involved  semantic  functions,  and  renaming  of  the  vocabulary,  it  allows  to  reuse  large  parts  of 
language  specifications  directly  in  other  specifications.  Programming  language  specifications  can  be  presented 
as  a  series  of  sub-languages,  each  reusing  its  predecessor  and  extending  it  with  new  features.  This  specification 
structure  has  been  used  in  AS.M  case  studies  [6, 10]  and  was  adapted  to  the  Montages  case  study  of  Oberon  [18]. 
Our  experience  with  Montages  shows,  that  such  sub-languages  are  useful,  working  languages,  that  can  be  exe¬ 
cuted,  tested,  and  explained  to  the  user  in  order  to  facilitate  understanding  of  the  whole  language.  The  design 
and  prototyping  of  a  language  is  much  more  productive  if  such  a  stepwise  development  and  testing  is  possible. 
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Abstract.  Software  architecture  is  widely  recognized  as  one  of  the  most  fundamental  concepts  in  software 
engineering,  because  of  the  fact,  that  today’s  software  systems  are  assembled  from  components  with  differ¬ 
ent  characteristics:  for  example  heterogenous,  legacy  or  distributed  systems.  At  the  software  architecture 
level,  designers  combine  subsystems  into  complete  systems  using  different  techniques,  e.g.  “Architecture 
Description  Languages”  (ADLs).  There  exists  a  number  of  ADLs,  each  of  which  is  specialized  for  one 
or  more  architectural  styles.  They  are  designed  by  different  research  groups  with  different  goals  in  mind 
corresponding  to  their  mental  model  on  how  softwme  architecture  can  be  expressed  in  the  most  efficient 
and  elegant  way.  As  a  result,  ADLs  are  not  compatible  with  each  other,  so  that  it  is  difficult  to  present 
a  homogeneous  view  of  the  software  architecture  of  a  system  assembled  from  different  components.  This 
paper  presents  an  approach  how  architectural  styles  can  be  combined  using  a  concept  of  ADL-interchange. 

1  Introduction 

The  complexity  of  many  of  today’s  software  developments  makes  it  often  not  reasonable  to  fix  a  certain  architec¬ 
tural  style  for  the  design  process  of  the  whole  software  system.  The  need  for  multiple  styles  can  come  from  either 
the  problem  domain  or  the  subparts  used  to  construct  the  system.  Imagine,  while  designing  a  mobile  phone  net¬ 
work  station,  there  are  several  architectural  styles,  that  need  to  be  combined.  For  example  for  receiving  signals 
from  the  mobile  phone  the  architect  may  choose  a  streaming  pipe-and-filter  style  to  handle  the  constant  flow 
of  repetitive  data.  For  processing  signals  may  be  an  event-based  style  is  chosen.  For  interacting  with  the  user, 
an  event-based  style  “plus”  a  pipe-and-filter  style  is  chosen.  For  that  part  of  the  subsystem  which  is  responsible 
for  the  collection  of  independent  components  or  special  customer  service  queries,  a  repository-based  approach 
is  chosen. 

Problem  statement:  This  high  level  descriptions  and  the  “plus”  between  these  styles  sound  attractive  on  paper, 
but  while  composing  different  architectural  styles,  architects  may  rely  on  ad  hoc  methods  in  trusting  their  own 
personal  experiences.  Current  practice  tackle  the  component  composition  problem  on  the  technical  layer  using 
e.  g.  scripting,  broker,  RPC,  event  channels  or  similar  approaches.  These  approaches  have  to  strong  emphasis  on 
solving  technical  interaction  problems.  The  realization  of  the  overall  problem  specification  is  covered  by  these 
low-level  problems. 

Architecture  Description  Languages  (ADLs)  belong  to  the  high-level  approaches.  ADLs  are  intended  to 
describe  the  system  structure  and  behavior  at  a  sufficiently  abstract  level  dealing  with  large  and  complex 
systems  [6].  A  lot  of  work  has  been  done  in  this  research  area,  e.g.  Aesop[10],  Unicon[ll],  ControlH[9],  MetaH[5], 
Rapide[14],  Darwin[15],  i7[19],  UNAS[18],  Wright[l],  GenVoca[4] 

But  the  heterogeneity  of  today’s  software  systems  forces  to  use  different  components  described  in  different 
ADLs.  This  leads  to  the  situation,  that  the  ADLs  become  nearly  unuseful,  because  each  ADL  operates  in  a  stand 
alone  fashion,  they  are  not  interoperable.  In  large  or  heterogenous  sj’-stems  many  of  these  common  aspects  of 
architectural  design  support  are  re-implemented  afresh.  This  means  a  lot  of  unnecessary  work,  which  is  probably 
one  of  the  reasons  for  the  often  discussed  question  [6]  in  software  architecture,  why  ADLs  are  only  taken  as  early 
life-cycle  specification  languages.  A  main  reason  for  this  interoperability  is  especially  the  underlying  semantics 
of  the  circhitectural  descriptions.  For  instance,  the  notion  of  a  component  in  ADL  A  could  be  a  different  one  as 
the  component  notion  in  ADL  B. 

*  This  research  was  supported  by  the  German  Research  Society,  Berlin-Brandenburg  Graduate  School  in  Distributed 
Information  Systems  (DFG  grant  no.  GRK  316) 
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In  the  following,  we  will  discuss  two  aspects:  how  to  use  different  ADLs  in  a  large  software  system  and  how 
to  perform  the  composition  task  on  the  architectural  level.  The  basic  idea  is,  that  there  exists  an  interchange 
level  between  the  different  architectural  description  means.  Therefore  we  introduce  a  service  layer  as  a  platform 
and  common  service  representation  layer  for  the  component  composition  (see  Figure  1):  The  system  description 
S  and  the  components  , . . . ,  Cn  are  mapped  to  corresponding  ASM  descriptions  S',  Cj  . . . ,  which  must  be 
consistent  with  their  unmapped  versions.  This  mapping  can  be  done  by  using  standard  techniques,  like  language 
translation,  or  the  definition  of  adaptors  and  wrappers.  Finally,  as  the  most  challenging  task,  we  transform 
the  overall  system  specification  S  step  by  step  in  such  a  way  that  it  finally  contains  explicit  references  to 
the  interfaces  of  the  existing  components  An  example  of  this  kind  of  transformation  is  the  use  of 

refinement  techniques  in  formal  description  methods  [3] .  The  result  of  these  stepwise  transformations  represents 
the  composition  specification  of  the  system.  We  will  call  this  final  specification  5+  in  order  to  emphasize  that 
it  realizes  the  “sum”  of  the  components.  Finally,  we  can  now  analyze  the  resulting  specification  5+  aiming  at 
the  identification  of  new  components  X  that  need  to  be  developed  besides  the  existing  ones.  As  a  side-effect,  the 
specification  of  these  newly  identified  components  can  then  automatically  be  obtained  from  the  specification 
and  developed  accordingly. 
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Fig.  1.  Service  layer  for  the  composition  of  components 


2  Why  Mapping  Architectural  Descriptions  To  Service  Layer  Representation? 

We  ^gue,  that  the  combination  of  different  ADLs  during  the  design  of  a  system  is  useful  at  least  because  of 
the  tollowing  reasons: 


-  If  an  architectural  description  problem  is  best  solved  by  a  certain  ADL  A,  then  the  use  of  this  A  is  the  most 
natural  thing  even  if  for  other  parts  of  the  system  A  is  not  appropriate,  and  therefore  other  ADLs  are  used. 

-  Developers  often  have  individual  favorites  for  describing  the  architecture  of  software.  If  a  developer  has  the 

eedom  to  choose  the  ADL  that  he  or  she  wants  -  if  it  is  appropriate  for  the  description  of  the  problem 
-  than  his  or  her  productivity  is  much  higher  than  if  he  or  she  is  forced  to  use  an  ADL  that  is  fixed  by 
the  project  policy.  Often  these  “favorite”  ADLs  are  none  of  the  well  known  languages  from  literature,  but 
individually  designed  “languages”  the  semantics  of  which  is  normally  given  by  an  implicit  agreement  among 
the  members  of  a  developer  team. 

Therefore,  what  is  needed  is  the  possibility  to  combine  different  ADLs  so  that 


-  for  different  portions  and/or  aspects  of  the  software  architecture  the  ADLs  that  fits  best  can  be  used  and 

-  the  resulting  combined  architectural  description  is  semantically  consistent  w.r.t.  the  underlying  models 

A  promising  way  to  solve  this  problem  is  to  provide  a  concept  for  an  interchange  of  ADLs.  In  principle 
there  exist  the  following  alternatives  for  an  interchange  between  different  ADLs: 
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Defining  a  union  language  subsuming  all  the  capabilities  of  the  existing  languages.  This  approach  seems 
to  be  unrealistic  because  of  the  manifold  characteristics  of  existing  ADLs.  There  cannot  be  “the  universal 
ADL  language”  that  masters  every  requirement  and  every  domain  specific  using  of  ADL. 

Defining  an  intersection  language  that  incorporates  the  features  being  contained  in  each  of  the  ADLs. 
Defining  a  service  ’’interchange”  providing  services  to  describe  and  composition  problems  based  on  ar¬ 
chitectural  descriptions. 

The  former  two  alternatives  imply  that  the  use  of  existing  ADLs  would  be  restricted,  because  they  would 
be  at  least  partially  replaced  by  a  new  ADL.  The  experience  gathered  for  the  “old”  ADLs  will  be  lost  and  users 
are  forced  to  learn  a  new  language.  The  advantage  of  the  third  approach  is,  that  existing  ADLs  can  be  used  as 
they  are,  because  the  interchange  is  not  done  on  the  language  level  but  on  a  basic  semantic  description  level. 
Thus,  the  latter  approach  is  much  more  promising,  because  there  is  no  need  to  convince  people  in  present  and  in 
future  to  use  a  “better”  approach  for  their  architectural  description.  For  the  same  reason,  the  third  alternative 
applies  also  for  the  integration  of  the  architecture  of  legacy  systems. 

2.1  What  are  the  problems  concerning  ADL  interchange? 

The  combination  of  ADL  A  and  B  is  less  complicated,  if  A  and  B  are  designed  to  describe  different  aspects 
of  the  software.  For  example,  if  the  static  structures  of  the  system  is  described  in  ADL  A,  and  the  dynamic 
behavior  is  encoded  in  ADL  B,  then  the  combination  of  these  two  descriptions  should  be  easier.  The  situation 
looks  quite  diflferent,  if  A  and  B  are  “competing”  ADLs  being  designed  for  similar  purposes.  In  this  case,  it  is 
very  important  to  carefully  analyze  the  underlying  semantics  of  A  and  B,  so  that  a  combination  is  possible  and 
the  consistency  can  be  checked. 

Therefore,  an  interplay  of  ADLs  can  only  be  achieved,  if  the  semantics  of  each  of  them  is  unambiguously 
defined.  Only  with  these  descriptions  it  is  possible  to  formulate  propositions  being  valid  for  the  combined 
architectural  description. 

As  a  consequence,  there  must  be  one  single  description  language  for  formulating  the  underlying  semantics 
of  each  of  the  ADLs.  Thus,  great  care  must  be  taken  in  selecting  the  right  one,  which  must  meet  at  least  the 
following  requirements: 

-  Due  to  the  fact  that  ADLs  are  manifold,  the  formal  description  language  must  be  universal  in  that  sense, 
that  it  is  possible  to  describe  the  feature  of  existing  ADLs.  Especially,  the  language  must  be  able  to  express 
static  structures  as  well  as  dynamic  behavior. 

-  In  order  to  be  able  to  make  statements  about  certain  properties  of  the  combined  architectural  description 
(e.g.  consistency,  liveness)  the  description  language  must  have  a  well-defined  mathematical  basis. 

-  If  during  the  process  of  combining  ADLs  is  turns  out,  that  aspects  being  important  for  the  interplay  of 
the  ADLs  are  not  expressible  by  any  of  the  participating  ADLs,  the  description  language  should  as  well  be 
usable  as  an  alternative  ADL  in  order  to  insert  missing  parts  in  the  architectural  description. 

-  The  previous  item  implies,  that  the  description  language  must  be  intelligible  for  people  involved  in  the 
software  architecture. 

-  Due  to  the  fact,  that  ADLs  often  describe  large  and  complex  software  system,  the  underlying  description 
language  must  be  scalable. 

-  Prom  a  practical  point  of  view,  the  description  language  should  have  a  notion  of  execution,  so  that  support 
tools  can  directly  generate  code  that  implements  the  interchange  level. 

The  Abstract  State  Machine  approach  [12]  seems  to  be  a  promising  candidate  for  being  used  to  describe 
software  architecture  models  and  the  semantics  of  ADLs: 

-  Abstract  State  Machines  (ASM)  is  an  universal,  mathematically  well-founded  method  which  is  capable  of 
the  description  of  static  structures  as  well  as  dynamic  behavior  of  system. 

-  ASMs  provide  the  possibility  to  choose  appropriate  levels  of  abstraction  according  to  the  problem  that 
should  be  described.  This  feature  is  also  important  with  respect  to  scalability. 

-  ASM  have  been  used  for  many  different  problem  areas.  In  the  context  of  this  work,  the  use  of  ASMs  in 
describing  the  semantics  of  programming  languages  (e.g.  [13] )  and  computer  architecture  (e.g.  [7] )  provides 
an  excellent  basis  for  the  task  of  describing  software  architectures. 

-  ASM  can  as  well  be  executed;  there  exist  several  tools  that  generate  executable  versions  of  the  ASM 
specification. 
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The  aim  of  this  approach  is  neither  the  development  of  a  new  architecture  definition  language,  nor  a  pre¬ 
scription  of  a  common  vocabulary,  nor  the  generation  of  “architectural  theorems”.  The  aim  is  to  form  a  basis 
for  the  combination  of  ADLs  by  using  existing  work  and  building  a  low  level  concept  that  can  directly  be  used 
to  implement  the  interchange  of  ADLs. 


3  Scenario:  Description  of  the  Composition 


We  assume  in  the  following,  that  we’re  working  within  the  service  layer.  It  serves  as  a  platform  for  the  archi¬ 
tectural  description  and  component  composition.  It  abstracts  from  architectural  styles  that  have  been  used  to 
ongmally  describe  the  components.  However,  the  translation  from  the  original  description  to  the  representation 
used  m  the  service  layer  must  be  carried  out  in  a  way,  that  no  semantic  information  gets  lost  The  format  of 
component  description  used  in  the  service  layer  is  very  similar  to  the  iT  ([19])  component  model,  containing  the 
services  being  provided  and  required  by  a  component  and  additionally  the  specification  of  the  functionality  and 
dynamic  behavior  of  the  component  in  ASM-notation. 

For  the  following  description  we  revisit  the  example  of  Section  1.  The  following  composition  problem  is 
described  as  an  example:  the  “processing  signals”  component  needs  information  from  the  “data  management” 
component  m  order  to  decide  whether  a  phone  connection  can  be  established  or  not,  because  of  potentially 
existing  limitations  contained  in  the  contract  of  a  customer  of  the  phone  company.  In  order  to  combine  these 
two  models,  we  translate  each  of  them  into  an  ASM  formalization.  The  union  of  these  formalizations  then  forms 
the  interchange  level  where  the  architectural  composition  can  actually  be  performed. 

As  pomted  out  m  the  previous  section  we  use  ASMs  for  this  purpose.  In  a  first  step,  the  architectural 
descriptions  of  the  example  mentioned  in  Section  1  are  automatically  translated  into  an  ASM  description  using 
techniques  hke  Montages  [2],  The  ASM  formalization  of  the  data  structures  of  the  “processing  signal”  component 


universes 

ConnectionData 

Process  =  {Receive, Connection, 

Timer, Disconnection} 

ProcessState  =  {active, passive} 
functions 

state:  Process->ProcessState 
CurrentConnection:  ->ConnectionData 
Connection  Process:  ->  Process 
relation 

access.check:  ConnectionData->Boolean 

For  the  “data  management”  component,  the  following  relation  is  needed  for  describing  the  composition: 
relation 

checkAccess : ConnectionData->Boolean 

Using  this  data  structures,  the  composition  of  the  two  components  can  be  specified  as  follows: 

if  state (ConnectionProcess)  =  active  then 
if  not  access_check(CurrentConnection) 

then 

access_check(CurrentConnection) : = 

checkAccess (CurrentConnection) 
elseif  access_check(CurrentConnection)  then 
!  ConnectiojttProcessRules 
else 

error  :=  "no  access  granted" 
state (ConnectionProcess)  :—  passive 
end  if 
endif 


In  the  next  steps,  these  abstract  description  must  be  stepwise  reflned  until  a  layer  is  reached  where  concrete 
e^  Je.  if  ‘he  interface  can  be  modeled.  These  refinement  steps  are 
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4  Related  work 

Currently,  the  only  effort  that  has  been  undertaken  to  build  an  interchange  of  ADLs  is  the  Acme  approach  [16] 
which  is  still  under  development.  Acme  is  a  software  architecture  description  language  that  aims  at  providing 
a  common  interchange  format  for  software  architecture,  so  that  different  tools  for  architecture  description 
languages  can  be  integrated.  The  main  difference  between  the  approach  presented  in  this  work  and  Acme  can 
be  described  as  follows:  Acme’s  goal  is  the  convergence  of  all  ADL  related  research  activities  into  the  Acme 
framework  and  tries  to  form  an  interchange  between  ADLs  on  the  language  level.  Our  approach  retains  existing 
ADLs  by  pushing  the  interchange  activities  on  a  lower  level,  the  semantic  description  level  of  these  ADLs. 

5  Conclusion 

Based  on  the  fact  that  architectural  design  fragments  using  different  architectural  description  means  often  need 
to  be  combined  into  larger  architectures  this  paper  presents  a  concept  how  to  compose  different  architectural 
styles.  This  will  be  achieved  by  providing  an  interchange  level  for  architectural  composition.  This  work 
is  focusing  on  ADLs  and  provides  basic  concepts  for  the  composition  based  on  ADLs.  In  contrast  to  existing 
approaches  for  combining  ADLs,  the  idea  presented  here  does  liot  build  on  a  consensus  between  ADL  developers 
in  present  and  future,  because  neither  a  superset  nor  an  intersection  of  existing  ADLs  need  to  be  introduced. 
Following  our  approach,  the  composition  keeps  the  freedom  of  choosing  the  architectural  description  means,  that 
is  most  suitable  for  the  actual  problem.  The  choice  of  an  ADL  is  not  restricted  by  the  needs  of  the  composition 
task. 
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Abstract.  An  abstract  framework  is  developed  to  describe  program  transformation  by  specializing  a  given 
program  to  a  restricted  set  of  inputs.  Particular  cases  include  partial  evaluation  [19]  and  Turchin’s  more 
powerful  “driving”  transformation  [33].  Such  automatic  program  speedups  have  been  seen  to  give  quite 
significant  speedups  in  practical  applications, 

This  paper’s  aims  are  similar  to  those  of  [18]:  better  to  understand  the  fundamental  mathematical  phe¬ 
nomena  that  make  such  speedups  possible.  The  current  paper  is  more  complete  than  [18],  since  it  precisely 
formulates  correctness  of  code  generation;  and  more  powerful,  since  it  includes  program  optimizations  not 
achievable  by  simple  partial  evaluation.  Moreover,  for  the  first  time  it  puts  Turchin’s  driving  methodology 
on  a  solid  semantic  foundation  which  is  not  tied  to  any  particular  programming  language  or  data  structure. 

This  paper  is  dedicated  to  Satoru  Takasu  with  thanks  for  good  advice  early  in  my  career  on  how  to  do 
research,  and  for  insight  into  how  to  see  the  essential  part  of  a  new  problem. 


1  Introduction 

1.1  History 

Automatic  program  specialization  evolved  independently  at  several  different  times  and  places  [13,31,33,  5,11, 
20].  In  recent  years  partial  evaluation  has  received  much  attention  ([19,6],  and  several  conferences),  and  work 
has  been  done  on  other  automatic  transformations  including  Wadler’s  well-known  deforestation  [37,7,26]. 

Many  of  these  active  research  themes  were  anticipated  in  the  1970’s  by  Valentin  Turchin  in  Moscow  [29, 30] 
in  his  research  on  supercompilation  (=  supervised  computation  and  compilation) ,  and  experiments  were  made 
with  implementations.  Examples  include  program  optimization  both  by  deforestation  and  by  partial  evaluation; 
the  use  and  significance  of  self-application  for  generating  compilers  and  other  program  generators;  and  the  use 
of  grammars  as  a  tool  in  program  transformation  [31,32,17].  Recent  works  on  driving  and  supercompilation 
include  [33, 14, 15, 27, 24, 22, 1, 36]. 


1.2  Goals 

The  purpose  of  this  paper  is  to  formulate  the  essential  concepts  of  supercompilation  in  an  abstract  and  language- 
independent  way.  For  simplicity  we  treat  only  imperative  programs,  and  intentionally  do  not  make  explicit  the 
nature  of  either  commands  or  the  store,  except  as  needed  for  examples. 

*  This  work  was  supported  in  part  by  the  Danish  Natural  Science  Research  Council  (DART  project)  and  by  an  Esprit 
Basic  Research  Action  (Semantique). 
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^  At  the  core  of  supercompilation  is  the  program  transformation  called  driving  (Russian  “progonka”).  In 
principle  driving  is  stronger  than  both  deforestation  and  partial  evaluation  [27,37, 12, 19],  and  an  example  will 
be  given  to  show  this  (the  pattern  matching  example  at  the  end  of  the  paper).  On  the  other  hand,  driving  has 
taken  longer  to  come  into  practical  use  than  either  deforestation  or  partial  evaluation,  for  several  reasons. 

First,  the  greater  strength  of  driving  makes  it  correspondingly  harder  to  tame;  cause  and  effect  are  less 
easily  understood  than  in  deforestation  and  partial  evaluation,  and  in  fact  it  is  only  in  the  latter  case  that 
self-apphcation  has  been  achieved  on  practical  applications.  Second,  the  first  papers  were  in  Russian,  and  they 
and  later  ones  used  a  computer  language  Refal^  unfamiliar  to  western  readers.  Finally,  the  presentation  style  of 
the  supercompilation  papers  is  unfamiliar,  using  examples  and  sketches  of  algorithms  rather  than  mathematical 
formulations  of  the  basic  ideas,  and  avoiding  even  set  theory  for  philosophical  reasons  [34]. 

We  hope  the  abstract  framework  will  lead  to  greater  practical  exploitation  of  the  principles  underlying 
supercompilation  (stronger  program  transformations,  more  automatic  systems,  new  languages),  and  a  better 
understanding  in  principle  of  the  difficult  problem  of  ensuring  termination  of  program  transformation. 

1.3  Preliminary  definitions 

First,  a  quite  abstract  definition  of  an  imperative  program  is  given,  as  a  state  transition  system.  In  our  opinion 
the  essence  of  the  “driving”  concept  is  more  clearly  exposed  at  this  level.  Later,  a  more  intuitive  flow  chart 
formalism  will  be  used  for  examples,  and  to  clarify  the  problem  of  code  generation. 

Definition  1.  An  abstract  program  is  a  quadruple  tt  =  (P,  5,  -i,po)  where  Po  e  P  and  ->  C  (P  x  5)  x  (P  x  5). 
Terminology:  P  is  the  set  of  program  points,  S  is  the  set  o/ stores,  is  the  transition  relation,  and  po  is  the 
imtial  program  point.  We  write  ->  in  infix  notation,  e.g.  (p, s)  -?■  (p', s')  instead  of  ((p, s),  M, s'))  A  state 
is  a  pair  (p,3)  E  P  X  S. 

A  store  such  as  [Xi-4  l:2:[3,Yi->2:(4:5):[]]  usually  maps  program  variables  to  their  values.  A  program  point 
may  be  a  flow  chart  node,  or  can  be  thought  of  as  a  label  in  a  program. 

Definition  2.  p  e  P  is  transient  if  (p,  si)  (p',  s')  and  (p,  s^)  -4-  (p",  s")  imply  p'  =  p",  i.e.  there  is  at  most 
onep  withip,.)  -4  (p  ,_).  State  (p,s)  is  terminal  if  (p,s)  ^  (p',s')  holds  for  no  (p',s').  The  abstract  program 
TV  IS  deterministic  if  for  all  states  (p,  s),  (p,s)  -4  (p',s')  and  (p,s)  -4  (p",s")  imply  p'  ~  p"  and  s'  —  s". 

Definition  3.  A  computation  (from  so  €  S)  is  a  finite  or  infinite  sequence 

(Po,so) -4  (pi,Si)  -4  (p2,  S2)  -4  . . . 

Notation:  subsets  of  S  will  be  indicated  by  overlines,  sosCS.  Given  this,  and  defining  to  be  the  reflexive 
transitive  closure  of  the  input/output  relation  that  n  defines  onsoCS  is 

/O(7r,so)  =  {(sojSt)  I  So  6  so,  (po,so)  -4*  (pt,Sf),  and  {pt,St)  is  terminal) 

More  concretely,  programs  can  be  given  by  flow  charts  whose  edges  are  labeled  by  commands.  These  are 
interpreted  by  a  command  semantics: 


C|_|  :  Command  ->•  (5  5') 

where  Command  and  S  are  unspecified  sets  (but  S  =  the  set  of  stores  as  above). 

Definition  4.  A  flow  chart  is  a  rooted,  edge-labeled  directed  graph  F  =  {P,E,po)  where  po  E  P  and  E  C 
P  X  Command  x  P  (the  edges  of  F).  We  write  p  ^  p'  whenever  (p,  C,p')  eE. 

If  p  p  thra  C  denotes  a  store  transformation,  e.g.  C  could  be  an  assignment  statement  changing  a  vari¬ 
able  s  value.  The  formulation  includes  tests  too:  the  domain  of  partial  function  CICJ  is  the  set  of  stores  which 
cause  transition  from  program  point  p  to  p'.  For  example,  command  “if  odd(X)  goto”  might  label  that  edge 
corresponding  to  “p:  if  odd(X)  then  goto  p'”  in  concrete  syntax.  ’ 

Definition  5.  The  program  denoted  by  F  is  =  (P,  S', -4,po),  where 


(p,  s)  -4  (p  ,  s')  if  and  only  if  s'  =  CICIs  for  some  p  ^  p' 


Srlrtnrl  T  ^  language  of  Markov  algorithms  extended  with  variables  and  two  kinds  of  brackets  to  create  tree 
if  ^  of  rewrite  rules,  used  to  transform  data  in  the  form  of  associative  and  possibly 

symbol  strings.  In  contrast  with  most  pattern  matching  languages,  most  general  unifiers  do  not  always  exist  ^ 
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2  Driven  programs,  without  store  transformations 

A  major  use  of  driving  (and  partial  evaluation)  is  for  program  specialization.  For  simplicity  we  begin  with  a 
rather  weak  form  of  driving  that  does  not  modify  the  store,  and  give  a  stronger  version  in  the  next  section. 

Given  partial  information  about  a  program’s  inputs  (represented  by  a  subset  sq  ^  -S'  of  all  possible  stores) , 
driving  transforms  program  n  into  another  program  that  is  equivalent  to  tt  on  any  initial  store  so  €  sq.  The 
goal  is  efficiency:  once  ltd  has  been  constructed,  local  optimizations  of  transition  chain  compression  and  reduced 
code  generation  can  yield  a  much  faster  program  than  tt,  as  seen  in  [18, 19]  and  many  others. 

A  useful  principle  is  to  begin  by  saying  what  is  to  be  done,  as  simply  as  possible,  before  giving  constructions 
and  algorithms  saying  how  it  can  be  accomplished.  We  thus  first  define  what  it  means  for  a  program  to  be 
a  “driven”  form  of  program  tt,  and  defer  the  question  of  how  to  perform  driving  to  Section  4. 

Intuitively  is  an  “exploded”  form  of  tt  in  which  any  of  tt’s  program  points  p  may  have  several  anno¬ 
tated  versions  (p,si),  (p,S2),  •  •  ••  Each  Sj  is  a  set  of  stores,  required  always  to  contain  the  current  store  in  any 
computation  hy  tt  a- 

(imputations  by  tcj  (state  sequences)  will  be  in  a  one-to-one  correspondence  with  those  of  tt,  so  nothing 
may  seem  to  have  been  gained  (and  something  lost,  since  izd  may  be  bigger  than  tt).  However,  if  control  ever 
reaches  an  annotated  program  point  (p,s)  in  tt^,  then  the  current  runtime  store  must  lie  in  s.  For  example,  s 
could  be  the  set  of  all  stores  such  that  the  value  of  variable  X  is  always  even. 

This  information  is  the  source  of  all  improvements  gained  by  partial  evaluation  or  driving.  Its  use  is  to 
optimize  Ud  by  generating  equivalent  but  more  efficient  code  exploiting  the  information  given  by  s.  In  particular 
some  computations  may  be  elided  altogether,  since  their  effect  can  be  achieved  by  using  the  s  at  transformation 
time;  and  knowledge  of  s  often  allows  a  much  more  economical  representation  of  the  stores  s  6  s. 


2.1  Abstract  formulation 

The  following  is,  in  our  opinion,  the  essential  core  of  the  driving  concept: 

Definition  6.  Given  program  tt  =  (F,  5,  ->,Po),  program  =  (F^,  5,  ->d,  (po,  So))  is  an  so-driven  form  of  tt  if 
Pd  C  P  X  F(S)  and  ud  satisfies  the  following  conditions. 

1.  ((p,s),s)  ((p',s'),s')  andses  imply  {p,s)  (p',s').  soundness 

2.  (p,s)  e  Pd,  (p,s)  ip',  s'),  and  s  £s  imply  that  there  exists  s'  such  that 

iip,s),s)-^diip',s'),s')  completeness 

iip,s),s)  -^d  Op',  s'),  s')  and  s  €s  imply  s'  £s'  invariance  of  s  £s. 

To  begin  with,  Pd  C  P  x  F(5),  so  a  program  point  of  ltd  is  a  pair  (p,s)  where  s  C  S  is  a  set  of  stores. 
The  soundness  condition  says  that  can  do  only  the  store  transformations  that  tt  can  do.  The  completeness 
condition  says  that  for  any  driven  program  point  (p,s)  of  any  store  transformation  that  tt  can  do  from  p  on 
stores  s  €  s  can  also  be  done  by 

Programs  may  in  principle  be  infinite,  but  in  practice  we  are  only  interested  in  finite  ones. 

The  significance  of  store  sets.  The  invariance  of  s  €  s  in  a  transition  ((p,s),s)  -^d  {(p',s'),s')  expresses  a 
form  of  information  propagation  carried  out  at  program  transformation  time  [14, 15]. 

One  can  think  of  a  store  set  as  a  predicate  describing  variable  value  relationships,  e.g.  “A  is  even”  or 
“X  =  Y  +  1  A  Z  <  Y" .  Store  sets  could  thus  be  manipulated  in  the  form  of  logical  formulas. 

This  view  has  much  in  common  with  regarding  statements  as  forward  or  backward  predicate  transformers, 
as  used  by  Dijkstra  and  many  others  for  proving  programs  correct  [10].  Further,  a  store  set  s  that  annotates 
a  program  point  p  corresponds  to  an  invariant,  i.e.  a  relationship  among  variable  values  that  holds  whenever 
control  reaches  point  (p,s)  in  the  transformed  program. 

Instead  of  formulas,  one  could  describe  store  sets  using  a  set  of  abstract  values  S,  using  for  example  a 
function  j  :  S  V{S)  that  maps  an  abstract  value  a  £  E  to  the  store  set  it  denotes.  In  logic  7  is  called  an 
interpretation,  and  Turchin  uses  the  term  configuration  for  such  a  store  set  description  [33]. 

This  idea  is  a  cornerstone  of  abstract  interpretation,  where  7  is  called  a  concretization  function  [9,2,16]. 
Gur  approach  can  thus  be  described  as  program  specialization  by  abstract  interpretation.  The  abstract  values 
are  constructed  “on  the  fly”  during  program  transformation  to  create  new  specialized  program  points.  This  is 
in  contrast  to  most  abstract  interpretations,  which  iterate  until  the  abstract  values  associated  with  the  original 
program's  program  points  reach  their  collective  least  fixpoint. 
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Lemma  1.  If  1^4  is  an  so-driven  form  o/tt,  then  for  any  sq  6  sq  there  is  a  computation 

(PO)  So) -t  (pi ,  si) ->■  (p2,  S2) -t  . . . 

if  and  only  if  there  is  a  computation 

{(PO,So),So)  -t  ((Pl,Sl),Si)  -t  ({P2,S2),S2)  “t  ... 

Proof.  If  follows  from  soundness,  “only  if”  by  completeness  and  invariance  of  s  €  s. 

Corollary  1.  JO(7r,  So)  =  70(7rrf,  So) 


Program  specialization  by  driving.  Informally,  program  rr  is  transformed  as  follows; 

1.  Given  tt  and  an  initial  set  of  stores  so  to  which  tt  is  to  be  specialized,  construct  a  driven  program  774.  In 
practice,  tt  will  be  given  in  flow  chart  or  other  concrete  syntactic  form,  and  finite  descriptions  of  store  sets 
will  be  used. 

2.  Improve  174  by  and  removing  unreachable  branches,  and  by  compressing  sequences  of  transient  transitions 

((p,s),s) -4  ((p',7),s') -7  .. . -4  ((p",?^),s") 

into  single-step  transitions 

((p,s),s)  ((p",F),s") 

3.  If  7r  =  where  F  is  a  given  flow  chart,  then  F4  is  constructed  and  improved  in  the  same  way;  by  compressing 
transitions,  and  generating  appropriately  simplified  commands  as  edge  labels. 

The  idea  is  that  knowing  a  store  set  s  gives  contextual  information  used  to  transform  174  to  make  it  run  faster 
Conditions  for  correct  code  generation  will  be  given  after  we  discuss  the  choice  of  store  sets  and  the  use  of 
alternative  store  representations  in  Section  3. 


2.2  Extreme  and  intermediate  cases 

In  spite  of  the  close  correspondence  between  the  computations  of  tt  and  774,  there  is  a  wide  latitude  in  the  choice 
of  TTrf.  Different  choices  will  lead  to  different  degrees  of  optimization.  For  practical  use  we  need  intermediate 
cases  for  which  774  has  finitely  many  program  points,  and  its  store  sets  s  are  small  enough  (i.e.  precise  enough) 
to  allow  significant  code  optimization.  ' 

We  will  see  a  pattern-matching  example  where  a  program  with  two  inputs  of  size  m,n  that  runs  in  time 
a  ■  m  •  n  can,  by  specializing  to  a  fixed  first  input,  be  transformed  into  one  running  in  time  h  ■  n  where  b  is 
independent  of  m. 

One  extreme  case  is  to  choose  every  s  to  be  equal  to  S.  In  this  case  774  is  identical  to  tt,  so  no  speedup  is 
gamed.  Another  extreme  is  to  define  774  to  contain  ((p,s),s)  ((p',  {s'}),  s')  whenever  (p,s)  -4  ip',  s'),  s  C  s, 

an  (p,  s)  £  P4.  In  this  case  774  amounts  to  a  totally  unfolded  version  containing  all  possible  computations  on 
mputs  from  sq. 


State  set  choice  and  code  generation.  The  extreme  just  described  will  nearly  always  give  infinite  programs 
It  IS  not  at  all  natural  for  code  generation,  as  it  deals  with  states  one  at  a  time. 

In  flow  chart  form,  a  test  amounts  to  two  different  transitions  p  ^  p'  and  p  ^  p"  from  the  same  p.  A  more 
interesting  extreme  can  be  obtained  from  the  following  principle;  the  driven  program  should  contain  no  tests 
that  are  not  present  in  the  original  program.  The  essence  of  this  can  be  described  without  flow  charts  as  follows. 


Definition  7.^  requires  no  new  tests  if  whenever  77  contains  (p,s)  {p',s'),  s  6  s,  and  774  contains 

{\p^s),s) -^4  {{p  ,S  ),s'),  then 


s'  D  {s2  I  asi  G  5  such  that  (p,si)  -4  (p',S2)  is  in  tt} 
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This  defines  the  new  store  set  s'  to  be  inclusive^  meaning  that  it  contains  every  store  reachable  from  any  store 
in  s  by  TT  transitions  from  plop'.  The  target  store  set  s'  of  a  driven  transition  ((p,  s),  s)  ((p',  s'),  s')  includes 
not  only  the  target  s'  of  s,  but  also  the  targets  of  all  its  “siblings”  si  €  s  that  go  from  pto  p'. 

For  deterministic  programs,  this  amounts  to  requiring  that  jt^  can  only  perform  tests  that  are  also  performed 
by  TT.  This  is  a  reasonable  restriction  for  code  generation  purposes,  but  is  by  no  means  necessary:  if  one  somehow 
knows  that  the  value  of  a  given  variable  x  must  lie  in  a  finite  set  X  =  {a,b,  .,k},  new  tests  could  be  generated 

to  select  specialized  commands  for  each  case  of  x  €  X. 

Even  though  these  new  tests  may  seem  unnecessary  since  they  were  not  present  in  the  original  program,  one 
often  gains  efficiency  because  the  value  of  x  will  be  known  exactly  in  each  of  the  specialized  commands,  leading 
to  smaller  subsequent  code.  See  the  discussion  on  “bounded  static  variation”  in  [19]. 

An  So-driven  form  of  n  can  always  be  obtained  by  choosing  equality  rather  than  set  containment  for  s',  and 
choosing  wa  to  contain  the  smallest  set  of  program  points  including  {po,so)  and  closed  under  the  definition  above. 
This  extreme  preserves  all  possible  information  about  the  computation  subject  to  the  inclusiveness  condition. 
It  can  be  used  in  principle  to  produce  a  “most  completely  optimized”  version  of  the  given  program,  but  suffers 
from  two  practical  problems: 

First,  this  So-driven  ira  will  very  often  contain  infinitely  many  specialized  program  points  {p,s).  Second,  its 
transition  relation  may  not  be  computable. 


Generalization.  It  is  a  subtle  problem  in  practice  to  guarantee  that  the  transformed  program  both  is  finite 
and  is  more  efficient  than  the  original  program.  A  solution  in  practice  is  not  to  work  with  the  mathematically 
defined  and  usually  infinite  store  sets  above,  but  rather  to  use  finite  descriptions  of  perhaps  larger  sets  s"  3  s' 
that  can  be  manipulated  by  computable  operations. 

Finiteness  of  the  transformed  program  can  be  achieved  by  choosing  describable  store  sets  that  are  larger 
than  s'  but  which  are  still  small  enough  to  allow  significant  optimizations. 

Turchin  uses  the  term  configuration  for  such  a  store  set  description,  and  generalization  for  the  problem  of 
choosing  configurations  to  yield  both  finiteness  and  efficiency  [33,35]. 


2.3  Driven  flow  charts 

We  now  reformulate  the  former  abstract  definition  for  flow  charts.  For  now  we  leave  commands  unchanged,  as 
Section  3  will  discuss  store  modifications  and  code  generation  together. 

Definition  8.  Given  flow  chart  F  =  (P,  E, po)  and  sq  Q  S,  Fa  =  {Pd,Ea,  {po,so))  is  an  so-driven  form  of  F  if 
Pd  C  P  X  P{S)  and  Fa  satisfies  the  following  conditions. 

1.  (p,s)  ^  {p',  s')  in  Fd  implies  p^  p'  in  F  soundness. 

2.  {p,s)  e  Pd,  s^  {},  and  p  ^  p'  in  F  imply  that  {p,s)  ^  ip',  s')  in  Fa  for  some  s'  completeness. 

3.  ip,t)  ^  (p',s')  in  Fd  and  s  es  and  s'  =  CJCIs  is  defined  imply  s'  G  s'  invariance  ofses. 

Theorem  1,  If  Fa  is  an  so-driven  form  of  F,  then  7r^‘‘  is  an  SQ-driven  form  ofn. 

Proof  This  is  easily  verified  from  Definitions  5  and  8,  as  the  latter  is  entirely  parallel  to  Definition  6. 


2.4  An  example 

Collatz’  problem  in  number  theory  amounts  to  determining  whether  the  following  program  terminates  for  all 
positive  n.  To  our  knowledge  it  is  still  unsolved. 

A:  while  n  ft:  1  do 
B: if  n  even 

then  (C:  n  :=  n  -G  2;  ) 
else  (D:  n  :=  3  *  n  -f  1;  ) 

fi 

od 


G: 
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Figure  2:  A  driven  version  of  the  same  program 


Its  flow  chart  equivalent  is  F  =  (P,  E,  0)  where  P  =  {A,  B,  C,  D,  G}  and  edge  set  E  is  given  by  the  diagram  in 
Figure  1.  The  program  has  only  one  variable  u,  so  a  store  set  is  essentially  a  set  of  values. 

We  use  just  four  store  sets: 

Even  {[n  t->  a;]  |  x  e  {0, 2, 4, . . .}} 

Odd  ={[nH>a;]  I  x€  {1,3,5,...}} 

T  =  {[n  a:]  j  a;  €  jV}  . 

-^  =  {} 

The  flow  chart  of  Figure  2  is  a  driven  version  of  P.  Specialized  program  points  {D,  ±)  and  (G  ±)  are  un- 
reachable  since  they  have  empty  store  sets.  The  driven  version,  though  larger,  contains  two  transient  transitions, 
trom  (A,  Even)  and  (B,  Even).  Transition  compression  redirects  the  branch  from  {D,  Odd)  to  (C,  Even)  to  give 
a  somewhat  better  program,  faster  in  that  two  tests  are  avoided  whenever  n  becomes  odd. 


3  Driven  programs,  with  store  transformations 

According  to  Definition  6,  a  driven  program  has  exactly  the  same  stores  as  ir.  As  a  consequence  the  only 
real  optimizations  that  can  occur  are  from  collapsing  transient  transition  chains,  and  little  computational 
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optimisation  occurs.  We  now  revise  this  definition,  “retyping”  the  store  to  obtain  more  powerful  transformations 
such  as  those  of  partial  evaluation  by  projections  [19,18, 21]  or  arity  raising  [25]. 

3.1  Abstract  formulation 

^Prom  now  on  Sd  will  denote  the  set  of  possible  stores  in  driven  program  tt^.  Given  the  knowledge  that  s  £s, 
a  store  s  of  tt  can  often  be  represented  in  the  driven  program  by  a  simpler  store  Sd  €  Sd-  For  example,  if 

s  =  {[X  i-)-l,  Y  y,  Z  1-4  3]  I  ye 

then  s  e  s  &t  TTd  program  point  (p,s)  can  be  represented  by  the  value  of  Y  alone  since  X,  Z  are  known  from 
context.  In  practice,  s  will  be  described  finitely,  e.g.  by  an  abstract  value  cr  in  description  set 

cr  —  [X  h4  1 ,  Y  h4  T  ,  Z  ^  3]. 

together  with  concretization  function  (or  interpretation)  7  :  i7  -4  7^(5).  To  formalize  this  abstractly,  we  assume 
given  a  function 

A  :  ViS)  X  Sd  S 

satisfying  the  following  two  properties  (note  that  A  is  written  in  infix  notation.); 

1.  sAsd  e  s  whenever  s  C  S,Sd  £  Sd,  and  sAsd  is  defined;  and 

2.  SoAsd  =  siAs'^  =  s  implies  Sd  —  s'^  . 

One  can  think  of  A  as  a  reconstruction  function  to  build  s  from  store  set  s  and  a  driven  store  Sd-  For 
example,  if  s  is  as  above  and  if  Sd  is,  say,  [Y  1-4  5]  then  we  would  have  sAsd  =  [X  h4  1,  F  i-4  5,  1-4  3]. 

The  restriction  sAsd  £  s  says  that  Sd  can  only  represent  a  store  in  the  current  s.  The  second  restriction  says 
that  A  is  injective  in  its  second  argument. 

The  previous  formulation  without  store  transformations  is  expressible  by  putting  S  —  Sd,  and  letting  sAsd  — 
Sd  when  Sd  =  Sd&  s,  with  sAsd  undefined  otherwise. 

We  will  see  that  allowing  alternative  representations  of  the  driven  stores  enables  much  stronger  program 
optimizations.  The  new  Definition  6  is  as  follows.  The  essential  idea  is  that  a  transition 

0,s) -4  (p',s')  =  (p,sAsd) (p',s'Asd) 

is  transformed,  by  a  kind  of  reassociation,  into  a  specialized  transition  of  form 

{iP,s),Sd)-^di(j)',s'),s'a) 

Defiinition  9.  Program  red  =  {Pd,Sd,-^d,{j?e^,SQ))  is  an  sq -driven  form  of  tt  —  (P,5, -4,po)  in  case  Pd  C 
P  X  V{S)  and  TTd  satisfies  the  following  conditions. 

1.  i{p,s),Sd)  -td  i{p',s'),s'^)  implies  s  As  d  and  s'  =  s'  As  ^  for  some  s,  s' ,  and  {p,  s)  (p' ,  s') .  soundness 

2.  {p,s)  £  Pd,  s  £  s,  and  {p,s)  -4  {p',s')  imply  there  are  sd,s'^,s'  such  that  s  =  sAsd,  s'  =  s'As'^,  and 

{{p,s),Sd) -td  i(p',s'),s'^).  completeness 

3.  i{p,s),Sd)  -4-c/  {{p',s'),s'^)  imply  s'As'^  £  s'  invariance  of  s£s 

Condition  3  is  actually  redundant,  as  it  follows  from  1  and  the  requirement  on  Z\. 

Lemma  2.  If  TTd  is  an  sq- driven  form  ofir,  then  for  any  computation 

(po,so) -t  (Pi,si) -4  (p2,S2) -t  ■  ■  • 
with  So  —  so^sod  there  is  a  computation 

i{PO,So),Sdo)  — td  ((pi,  Si),  Sdi)  -Td  {iP2,S2),Sd2)  -4d  ... 

with  Si  =  SiAsdi  for  all  i.  Further,  for  any  such  TTd  computation  with  sq  =  soAsdo,  there  is  a  corresponding  tt 
computation  with  Si  =  SiAsdi  for  all  i. 

The  first  part  follows  from  initialization  and  completeness,  and  the  second  by  soundness  and  invariance.  The 
corollary  on  equivalent  input/output  behaviour  requires  a  modification. 

Corollary  2.  If  every  sq  £  sq  equals  soAsod  for  some  sod,  then  IO{tt,so)  = 

{(so'^sodjsAsd)  I  SoAsod  and  ({ipo,so),sod),{ip,s),sd))  £  IO{TTd,sod)] 
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3.2  Correctness  of  code  in  driven  flow  charts 

We  now  redefine  driven  flow  charts  to  allow  different  code  in  Fa  than  in  F.  Commands  labeling  edges  of  Fa  will 
be  given  subscript  d.  Their  semantic  function  is: 

Cdl-I  :  Commanda  -t  (Sa  So) 

The  follovdng  rather  technical  definition  can  be  intuitively  understood  as  saying  that  for  each  paired  p  ^  p' 
and  (p,s)  =4  {p',s'),  the  diagram  corresponding  to  equation 


ClClisAsa)  =  s'AiCalCajsa) 

commutes,  provided  that  various  of  its  subexpressions  are  defined. 

CalCal 


S, 


Sd 


sA  _ 


cm 


s' A  _ 


S 


Definition  10.  Given  flow  chart  F  =  {P,E,po)  and  so  CS,Fa  =  {Pa,Ba,  (po,so))  is  an  ?o-driven  form  of  F 
V  Pd  Q  P  X  r{S)  and  Fa  satisfies  the  following  conditions. 

1.  For  each  {p,s)  ^  (p',s')  G  Ea  there  exists  p  ^  p'  £  E  such  that  s  =  sAsa  and  s'  =  ClCJs  are  defined  if 

and  only  if  Sa  —  Cd\Cd\sd  and  s'  —  s'As'a  are  defined  soundness 

2.  If  p^  p ,  (p,s)  G  Pd,  and  both  s  =  sAsa  and  s'  —  C|C]]s  are  defined,  then  Fa  has  an  edge  (n  s)  ^  M  s') 

suchthats'  =  s'AiCdlCdlsd)  completeness 

3.  {p,s)  =4  {p  ,s  ),  p  =>  p' ,  and  both  s  —  sAsa  and  s'  =  C|I(7|s  are  defined  imply  Cd\Cd\sd  E  s' 

invariance  of  s  es. 

Theorem  2.  If  Fa  is  an  so-driven  form  of  F,  then  is  an  So-driven  form  of  . 

Proof  This  is  easily  verified  from  Definitions  5  and  10,  as  the  latter  is  entirely  parallel  to  Definition  9. 


3.3  Partial  evaluation  by  projections 

.Suppose  there  is  a  way  to  decompose  or  factor  a  store  s  into  static  and  dynamic  parts  without  loss  of  information 
^  basic  Idea  in  [18, 19]).  A  data  division  is  a  triple  of  functions  {stat :  S  Ss,dyn  :  S  Sd,pair  iSsXSa^S) 
The  ability  to  decompose  and  recompose  without  information  loss  can  be  expressed  by  three  equations: 

pair{stat{s),dyn{s))  =  s 
stat{pair{vs,Vd))  =Vs 
dyn{pair{vs,Vd))  =  va 


by  an  5  -  D  vector,  for  instance  SDD 
species  the  division  of  5  =  into  M xA^  where  pairin,  (x,  a))  =  (n,  x,  a),  stat(n,  x,  a)  =  n,  and  dj/n(n,  r,  a)  == 
{a:,o).  Using  this,  the  program  '  ’  \  ,  j 


f{n,x)  =  g{n,x,l) 

gin,  a:,  o)  =  if  n  =  0  then  a  else  g{n  —  1,  x,  x  *  a) 
can  be  specialized  with  respect  to  known  n  =  2  to  yield: 

f2(x)  =g2(x,l) 

g2(x,a)  =  gi{x,x*  a) 
giix,a)  =  go{x,x*a) 
goix,a)  =  l 

which  by  transition  compression  can  be  further  reduced  to 


f2ix)  =  x*x 
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Relationship  between  driving  and  projections.  This  method  can  be  interpreted  in  current  terms  as 
specialization  by  using  store  sets  that  are  equivalence  classes  with  respect  to  static  projections,  i.e.  every  store 
set  is  of  the  following  form  for  some  Vg  e  Ss‘- 

Sv,  =  {s  I  stat{s)  =  Us} 

Store  reconstruction  can  be  expressed  by  defining:  Sv.^va  =  pair{vs,vd).  A  specialized  program  in  [18,19] 
only  contains  transitions  of  form 


{(p,stat{s)),dyn{s)) i(p',stat{s')),dyn{s')) 

where  tt  contains  (p,s)  ip',  s').  This  corresponds  to  our  soundness  condition.  The  set  “poly”  in  [18,19])  is 
constructed  so  if  (po,so)  ->*  (p,  s)  by  tt  for  some  Sq  €  sq,  then  poly  and  so  na  contains  a  specialized  program 
point  (p,  stat{s)),  ensuring  completeness.  Invariance  of  s  G  s  is  immediate  since  every  specialized  state  is  of  the 
form  ((p,s„J,Urf),  and 

Sv,Avd  —  pair{vs,Vd)  G  {s  |  stat{s)  =  Us} 
since  stat{pair{vs,Vd))  =  Ug.  The  following  definition  is  central  in  [18, 19]: 

Definition  11.  Function  stat  :  S  Sd  is  congruent  if  for  any  tt  transitions  {p,s)  (p',s')  and  (p,si) 

(p'jS'^),  if  stat(s)  —  stat(si),  then  stat(s')  =  stat(s'i). 

This  is  essentially  the  “no  new  tests”  requirement  of  Definition  7. 


4  An  algorithm  for  driving 


The  driving  algorithm  of  Figure  3  manipulates  store  descriptions  ct  G  T",  rather  than  store  sets.  For  the  x” 
example  above,  X"  is  the  set  of  all  store  descriptions  a  of  the  form 

cr  =  [ni-^  u, X  1-4  T, o  h->- T] 

where  u  G  A7.  We  assume  given  a  concretization  function  7  :  X  -4  'P(S')  defining  their  meanings,  and  that  the 
test  “is  ja  —  {}?”  is  computable,  i.e.  that  we  can  recognize  a  description  of  the  empty  set  of  stores. 

In  addition  we  assume  given  a  store  set  update  function 

S  :  Command  x  X  -4  X 


and  a  code  generation  function 


Q  :  Command  x  X  -4  Commandd 


Correctness  criterion.  For  any  C  G  Command,  a  e  S,Sd£  Sd,  let  a'  =  <S(C,  cr)  and  Cd  =  G{C,  a).  Definition 
10  requires  C\C1['yaAsd)  —  {')(7')A{Cd\Cd\sd)  under  certain  conditions  (where  t  =  t'  means  both  are  defined 
and  the  values  are  equal) : 


1.  s  =  {'y(T)Asd  and  s'^  =  CdlCdjsd  imply  CIC|s  =  (7cr')^s'd 

2.  s'  =  CfCJs  and  s  =  ija)Asd  imply  s'  =  {')cr')A{CdlCdlsd) 

3.  s  =  (yaJAsd  6  70-  implies  Cd\Cd\sd  G  7cr' 


soundness 
completeness 
invariance  of  s  G  s. 
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read  F  =  {P,E,po); 
read  ao; 

Pending  :=  {(po.cro)}; 

SeenBefore  ;=  {}; 

Pd  {(po,CTo)}; 

Ed-^  {}; 

while  3(p,  cr)  G  Pending  do 
Pending  :=  Pending  \ 

SeenBefore  :=  SeenBefore  U  {{p,  a)}; 
forall  p'  e  E  do 
<t'  :-<S(cr,C); 
if  7cr'  {}  then 

Pd  ~P’rfU{(p',ff')}; 

if  (p',cr')  ^  SeenBefore  then  add 

Cd~g(<r,C); 

Add  edge  (p,a)  ^  (p',cr')  to  Ed; 
Pd  :=  (Pd,Ed,ipo,cro)); 

Figure  3:  An  algorithm  for  driving 


(*  Unprocessed  program  points  *) 

(*  Already  processed  pgm.  points  *) 
(*  Initial  program  points  *) 

(*  Initial  edge  set  *) 

{*  Choose  an  unprocessed  point  *) 


(*  Scan  all  transitions  from  p  *) 

(*  Update  store  set  description  *) 

(*  Generate  code  if  nontrivieJ  *) 

to  Pending; 

{*  Generate  code  *) 

(*  Extend  flow  chart  by  one  edge  *) 


4.1  Example:  pattern  matching  in  strings 


A  way  to  test  a  program  transformation  method’s  power  is  to  see  whether  it  can  derive  certain  well-known 
e  cient  programs  from  equivalent  naive  and  inefficient  programs.  One  of  the  most  popular  of  such  tests  is  to 
generate  from  a  naive  pattern  matcher  and  a  fixed  pattern,  an  efficient  pattern  matcher  as  produced  by  the 
Knuth-Morris-Pratt  algorithm.  We  shall  call  this  the  KMP  test  [27].  •  ^ 

First  we  give  a  program  for  string  pattern  matching. 


match  p  s  =  loop  p  s  p  s 

loop  []  5s  op  os  =  True 

loop  (p  :  pp)  []  op  os  =  False 

loop  (p  :  pp)  (s  :  ss)  op  os  =  if  p  =  s  then  loop  pp  ss  op  os  else  next  op  os 

next  op  0  =  False 

next  op  (s  :  ss)  =  loop  op  ss  op  ss 


For  conciseness  m  exposition,  we  specify  the  store  sets  that  are  encountered  while  driving  match  AAB  u  by 

J?  assumed  to  range  over  all  possible  data  values.  Given  this^ 

the  result  of  ffiivmg  can  be  described  by  the  configuration  graph  seen  in  the  Figure  ending  this  paper  (where 
some  intermediate  configurations  have  been  left  out).  More  details  can  be  seen  in  [27].  ^ 

The  program  generated  is: 


/  ^  =  Iaab u 

/aab  D  —False 

fAAB  {s  :  ss)  =  g  s  ss 


g  s  ss 
IabW 
fAB  {s  :  ss) 
hs  ss 

/bD 

Jb  {s  :  ss) 


—  if  A  —  s  then  Jab  ss  else  Jaab  ss 
=  False 

=  h  s  ss 

—  if  A  =  s  then  ss  else  g  ss 
=  False 

—  if  A  =  s  then  g  s  ss  else 

if  B  =  s  then  true  else  h  s  ss 
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This  is  in  essence  a  KMP  pattern  matcher,  so  driving  passes  the  KMP  test.  It  is  interesting  to  note  that  driving 
has  transformed  a  program  running  in  time  0{m-n)  into  one  running  in  time  0{n),  where  m  is  the  length  of 
the  pattern  and  n  is  the  length  of  the  subject  string. 

Using  configurations  as  above  can  result  in  some  redundant  tests,  because  we  only  propagate  positive  infor¬ 
mation  (what  term  describes  the  negative  outcome  of  a  test?).  However  this  problem  can  easily  be  overcome  by 
using  both  positive  and  negative  environments,  see  [15]. 

Partial  evaluators  of  which  we  know  (other  than  the  supecompiler)  cannot  achieve  this  effect  without  non¬ 
trivial  human  rewriting  of  the  matching  program. 


match  AAB  u 

1 

(Taab)  loop  AAB  u  AAB  u  _ 

i 

(g)  A  =  s  loop  AB  ss  AAB  (s  :  ss) 

□  next  AAB  (s  :  ss) 

(fAs)  loop  AB  ss  AAB  A  :  ss  _ 

I 

(h)  A  —  s  -t  loop  B  ss  AAB  (A  ;  s  :  ss) 

□  next  AAB  {A:  s  :  ss) 

(fe)  loop  B  ss  AAB  A:  A:  ss  _ 

B  =  s  —t  loop  []  ss  AAB  (A  ;  A  :  s  :  ss) 

□  next  AAB  (A  ;  A  :  s  :  ss) 

loop  []  ss  AAB  A  :  A  :  B  ;  ss 
True 


False 

next  AAB  (s  ;  ss)  {tAAa) 


False 

next  AAB  (A  :  s  :  ss) 

loop  AAB  (s  :  ss)  AAB  (s  :  ss)  (g) 

False 

next  AAB  (A:  A:  s  :  ss) 

loop  AAB  (A  ;  s  ;  ss)  AAB  (A  :  s  ;  ss) 

A  =  A  ->  loop  AB  (s  :  ss)  AAB  (A  :  s  :  ss) 
O  next  AAB  (A  :  s  :  ss) 

loop  AB  (s  :  ss)  AAB  (A  :  s  :  ss)  (h) 


4.2  Finiteness  and  generalization 

E  is  usually  an  infinite  set,  causing  the  risk  of  generating  infinitely  many  different  configurations  while  driving. 
Turchin  uses  the  term  generalization  for  the  problem  of  choosing  configurations  to  yield  both  finiteness  and 
efficiency  [33,35]. 

The  idea  is  to  choose  elements  a'  =  S{a,  C)  which  are  “large  enough”  to  ensure  finiteness  of  the  transformed 
program,  but  are  still  small  enough  to  allow  significant  optimizations.  This  may  require  one  to  ignore  some 
information  that  is  available  at  transformation  time,  i.e.  to  choose  descriptions  of  larger  and  so  less  precise  store 
sets  than  would  be  possible  on  the  basis  of  the  current  <7  and  C. 

How  to  achieve  termination  without  overgeneralization  is  not  yet  fully  understood.  Turchin  advocates  an 
online  technique,  using  the  computational  history  of  the  driving  process  to  guide  the  choices  of  new  a'  [35].  It  is 
as  yet  unclear  whether  self-application  for  practical  compiler  generation  can  be  achieved  in  this  way,  or  whether 
some  form  of  preprocessing  will  be  needed.  If  offline  preprocessing  is  needed,  it  will  certainly  be  rather  different 
from  “binding-time  analysis”  as  used  in  partial  evaluation  [19]. 
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Abstract.  Existing  partial  evaluators  usually  fix  the  strategy  for  binding-time  analysis.  But  a  single 
strategy  cannot  fulfill  all  conflicting  analysis  goals  without  leading  to  compromises  regarding  precision, 
termination,  and  code  explosion  in  partial  evaluators.  Our  goal  is  to  improve  the  usability  of  partial  eval¬ 
uator  systems  by  developing  an  adaptive  approach  that  can  accommodate  a  variety  of  different  strategies 
ranging  from  maximally  polyvariant  to  entirely  uniform  analysis,  and  thereby  make  off-line  specialization 
more  practical  in  a  realistic  setting.  The  core  of  the  analysis  has  been  implemented  in  FSpec,  an  oflfline 
partial  evaluator  for  a  subset  of  Fortran  77. 


1  Introduction 


Partial  evaluation  of  imperative  programs  was  pioneered  by  Ershov  and  his  group  [8,3];  later  Jones  et  al.  [11] 
mtroduced  binding-time  analysis  (BTA)  to  achieve  self-application  of  a  partial  evaluator.  This  offline  approach 
to  partial  evaluation  has  been  studied  intensively  since  then. 

Hovsrever,  not  much  attention  has  been  paid  to  the  properties  of  the  binding-time  analysis  in  offline  partial 
evaluation  (notable  exceptions  are  [6,13,4,2]).  This  is  surprising  because  the  annotations  a  BTA  produces 
guide  the  specialization  process  of  an  offline  partial  evaluator  and,  thus,  control  the  quality  of  the  prograni 
transformation.  The  choice  of  the  annotation  strategy  is  therefore  the  most  decisive  factor  in  the  design  of  an 
offline  partial  evaluator. 

Existing  offline  partial  evaluators  /la;  a  particular  binding-time  strategy  (e.g.,  [1,5, 7, 12]).  None  of  them  allow 
the  partial  evaluator  to  function  with  different  levels  of  precision,  and  all  systems  implement  different  strategies 
based  on  decisions  taken  on  pragmatic  grounds.  The  growing  importance  of  non-trivial  applications  with  varying 
specialization  goals  (e.g.  interpreter  specialization  vs.  software  maintenance)  motivated  us  to  examine  a  more 
flexible  approach  to  binding-time  analysis  for  imperative  languages.  Our  goal  is  to  improve  the  usability  of 
partial  equation  systems  by  developing  an  analysis  framework  that  allows  an  easy  adaptation  and  control  of 
diiferent  binding-time  strategies  within  the  same  specialization  system. 

In  this  paper  we  examine  the  design  space  of  binding-time  strategies  and  develop  a  framework  to  formalize 
dmerent  strategies  that  allows  a  partial  evaluator  to  function  with  different  levels  of  granularity  We  claim  that 
It  is  expressive  enough  to  cover  all  existing  strategies  and  allows  the  design  and  comparison  of  new  strategies. 

ana^sis  enpne  is  implemented  for  FSpec,  an  offline  partial  evaluator  for  a  subset  of  Fortran 
77  [12j.  We  assume  familiarity  with  the  basic  notions  of  offline  partial  evaluation,  e.g.  [10,  Part  II]. 


2  Problem  Source:  One  Size  Does  Not  Fit  All 

ffl  existing  p^ial  evaluators,  the  strategy  of  the  binding-time  analysis  (BTA),  and  thus  its  precision,  is  fixed  at 
desi^-time;  m  essence  assuming  ‘One  Size  Fits  AH’.  The  most  popular  strategy  for  BTA,  due  to  its  conceptual 
simplicity,  is  to  annotate  programs  using  uniform  divisions  [10].  In  this  case  one  division  is  valid  for  o/l  program 
points.  A  polyvariant  BTA  allows  each  program  point  to  be  annotated  with  one  or  more  divisions 

Figure  1  shows  two  pieces  of  source  programs  and  for  each  the  result  of  two  different  specializations:  One 
directed  by  a  uniform  BTA  (column  A)  and  one  directed  by  a  polyvariant  BTA  (column  B).  We  assume  poly- 
vanant  program  point  specialization  [3,10]  (a  program  point  in  the  source  program  may  be  specialized  wrt 
different  static  stores).  Program  Monitor  updates  variable  Val  depending  on  the  value  of  flag  Upd  (we  assume 

that  function  f  has  no  side  effects  and  that  f  (100)  =  5).  Program  Affine  repeatedly  calls  procedure  p.  Variables 
a,  b  and  count  are  global.  r  ^ 
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Program 

Source  code 

Res.  code  (uniform  BTA) 

Res.  code  (poly.  BTA) 

Monitor 

Upd  =  FALSE 

Val  =  100 

OutVal  =  0 

CurVal  is  dynamic 

1 

10:  IF  Upd=TRUE  THEN 
11:  Val:=CurVal; 

12:  ENDIF; 

13:  OutVal :=f (Val); 
14:  OUTPUT  OutVal; 

lA 

10:  Val: =100; 

11:  0utVal:=f (Val) ; 

12:  OUTPUT  OutVal; 

' 

IB 

10:  OUTPUT  5; 

Affine 

a  =  2 

b  =  6 

X  is  dynamic 
count  is  dynamic 

2 

10:  IF  a>0  THEN 

11:  p(x); 

12:  GOTO  10; 

13:  ENDIF; 

100:  PROCEDURE  p(y): 
101:  a:=a-l; 

102:  b:=b+y; 

103:  count  :=coimt+l; 
104:  RETURN; 

2A 

10:  b:=5: 

11:  p(x); 

12:  p(i); 

100:  PROCEDURE  p(y) : 
101:  b:=b+y; 

102:  count :=count+l; 
103:  RETURN; 

2B 

10:  pKx); 

11:  p2(x); 

100:  PROCEDURE  pl(y): 
101:  b:=5+y; 

102:  count :=count+l; 
103:  RETURN; 

104:  PROCEDURE  p2(y): 
105:  b:=b+y; 

106:  count ;=count+l; 
107:  RETURN; 

Fig.  1.  Problem  source:  One  BTA  is  not  best  for  all  source  programs. 


For  Monitor,  the  polyvariant  BTA  (IB)  clearly  achieves  the  best  specialization  because  result  5  is  computed 
at  specialization  time.  The  uniform  BTA  (lA)  must  consider  Val  dynamic  and  can  therefore  not  allow  the 
call  of  f  to  be  computed  at  specialization  time.  For  Affine,  the  uniform  BTA  (2A)  seems  to  provide  a  better 
specialization.  The  polyvariant  BTA  (2B)  recognizes  that  the  value  of  b  is  sometimes  static  (in  the  first  round 
of  the  loop)  and  creates  an  extra  instance  of  procedure  p.  This  leads  to  undesirable  duplication  of  code  (which 
is  more  dramatic  for  larger  programs).  Almost  all  existing  partial  evaluators,  such  as  C-Mix  [1]  and  FSpec  [12], 
give  (1A,2A);  Tempo  [7]  gives  (1A,2B). 

To  conclude,  the  uniform  BTA  is  preferable  for  Affine  and  the  polyvariant  BTA  is  preferable  for  Monitor.  A 
partial  evaluator  that  is  confined  to  one  of  the  two  strategies,  A  or  B,  may  not  be  suitable  for  the  task  at  hand. 
In  such  a  case  the  user  has  to  resort  to  rewriting  the  source  program  to  influence  the  specialization.  This  is  why 
we  are  looking  for  a  more  elegant  and  flexible  solution  to  BTA. 

3  Binding-Time  Analysis  and  Maximal  Poly  variance 

We  consider  only  first-order  deterministic  languages,  and  assume  that  any  program  has  a  set  of  program  points. 
Examples  include  labels  in  a  flow  chart  language  and  function  names  in  a  functional  language.  Their  essential 
characteristics  is  that  computation  proceeds  sequentially  from  program  point  to  program  point  by  execution  of 
a  series  of  commands,  each  of  which  updates  a  program  state. 

Definition  1.  A  programming  language  is  a  tuple  L  =  {V,C,S,  [•]),  where  [-I  :  C  ->•  5  ->  7^  x  5  *s  a  paHial 
function.  Terminology:  V  is  the  set  of  program  points,  C  is  the  set  of  commands,  S  is  the  set  of  stores,  and  [-1 
is  the  semantics  of  L.  A  state  is  a  pair  {p,o)  €  T’  x  <S. 

Definition  2.  Let  L  he  a  programming  language,  then  an  L-program  is  a  partial  mapping  P  :V  C,  where 
V  is  the  set  of  program  points  of  L  and  C  is  the  set  of  commands  of  L.  We  assume  each  L-program  P  has  the 
property  that  Vcr  G  «S.Vj?  €  dom(P)  :  |F(p)|(t  =  {p',(7')  implies  p'  G  dom{P),  if  defined.  Notation:  The  initial 
program  point  of  a  program  P  is  denoted  by  po. 

Definition  3.  Let  P  be  an  L-program,  define  computation  step  as  transition  relation  -AC  (V,S)  x  {V,S)  such 
that  (p,cr)  ->  (p',a')  iff  lP(p)ja  =  (p',cr'}  is  defined.  A  computation  (from  ao  G  S)  is  a  finite  or  infinite 
sequence 

(Po.CTo)  -A  (pi,t7i)  -A  ... 

A  store  is  usually  a  finite  function  tr  =  [xi  ka  ui, . . .  ,a;„  (A  u„]  which  maps  variables  x  e  W  to  values  v  e  V, 
where  notation  cr{xi)  denotes  value  u,  in  (j. 
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n  :  1 


1  :  1 


1 :  m 


Fig.  2.  Granularity  of  binding-time  analysis 

Offlme  partial  evaluation  [10]  is  done  in  two  steps:  a  binding-time  analysis  (BTA)  followed  by  a  specialization 
phase.  First,  the  source  program  is  analyzed  over  a  domain  consisting  of  two  abstract  values,  S  and  D,  where  S 
(static)  represents  a  value  known  at  specialization  time,  D  (dynamic)  represents  a  value  that  may  be  unknown 

at  specialization  time.  Then  the  source  program  is  specialized  wrt.  known  values  following  the  annotations  made 
by  the  BTA. 

Definition  4.  A  binding-time  value  is  a  value  b  e  B  where  B  =  {S,D}.  A  binding-time  store  :  A”  B 
maps  variables  to  binding-time  values.  A  binding-time  semantics  Hfcia  :  C B B  maps  a  command  and  a 
hmding-time  store  to  a  binding-time  store.  A  binding-time  state  is  a  pair  {pj),  where  p  is  a  program  point  and 
p  IS  a  binding-time  store. 


Definition  5.  Let  P  be  an  L-program,  define  binding-time  step  as  transition  relation '’-^C  (P  B)  x  (P  B)  such 
that  (p,fi)^-^(p',fi')  iff  -  v,; 

==  0'  A  3cr,cr'.(p,cr) -)■  (p',cr') 

Given  lP(p)lMa0  =  0',  we  expect  that  for  any  transition  (p,cr)  -4  (p',a'),  the  values  of  the  variables  classified 
^  6  in  ^  must  be  computable  from  the  values  of  the  variables  classified  as  S  in  ,5.  In  other  words,  we  expect 
1.16«a  to  be  a  realization  of  the  congruence  rules  of  L  [10]. 

The  t^k  of  a  BTA  is  to  compute  from  bt-state  (po,0o)  of  an  L-program  P,  a  set  of  bt-states  (denoted 
by  Ann).  Th^  set  is  always  finite  because  a  program  has  finitely  many  variables  and  there  are  finitely  many 
bt-values.  A  BTA  can  compute  Ann  in  many  different  ways.  The  set  of  bt-states  induced  by  the  bt-semantics 
ilMa  IS  maximally  polyvariant.  To  keep  our  discussion  language-independent,  we  shall  clearly  separate  the  set 
oi  bt-statGS  from  the  syntactic  annotation  of  a  source  program. 

Defimtion  6.  Let  P  be  an  L-program  and  let  0o  be  an  initial  bi-store,  then  po}ymax{P,  0o)  denotes  the  set  of 
bt-states  defined  by  ^  >  j 

polymax{P,  0o)  {(p,  0)  |  (po,  0o)  (p,  0)} 


4  Dimensions  of  Binding-Time  Analysis 


A  binding-time  strategy  for  realistic  applications  has  to  accommodate  three  important,  but— unfortunately 
often  conflicting  goals:  ^ 


1.  Increasing  staticness  by  more  precise  analysis. 

2.  Taming  code  explosion  by  reducing  the  amount  of  polyvariance  at  specialization  time. 

3.  Ensuring  termination  of  the  specialization  process  by  dynamizing  operations  that  lead  to  infinite  trans- 


A  uniform  BTA  computes  one  division  that  is  valid  for  all  program  points  (Fig.  2).  For  small  programs  this 
assumption  is  reasonable,  but  not  for  larger  applications  because  of  the  non-locality  of  binding-time  effects 
Pomtwise  and  polyvariant  analyses  are  flow-sensitive.  They  allow  programs  points  to  be  annotated  with  one 
or  more  local  divisions.  They  can  significantly  improve  staticness  in  programs  and  avoid  the  need  for  manual 
bindmg-time  improvements.  For  example,  the  BTA  of  Tempo  [9]  computes  pointwise  divisions  for  basic  blocks 
^d  polyv^iant  divisions  on  the  procedure  level.  Increased  staticness  in  a  program  does  not  always  come  for 
free.  Non-termination  of  the  specialization  process  and  code  explosion  of  the  generated  programs  axe  some  of 
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^uniform  ~  ^  “  C 

^poinivjise  —  S uniform  A  ^  —  _p  . 

^ polymax  “ 


Fig.  3.  Three  well-known  BTA  strategies. 


Source  code 

Annotations 

10:  IF  Upd=TaUE  THEN 

(5, 5,  A  5) 

11:  Val:=CurVal; 

{S,S,D,S) 

12:  ENDIF; 

{S,D,D,S) 

13:  OutVal:=f(Val)i 

{S,S,D,S}  {S,D,D,S) 

14:  OUTPUT  Out Val; 

{S,S,D,S)  (S,D,D,S) 

Fig.  4.  Polyvariant  annotation  of  Monitor.  (Upd,Val,CurVal,OutVal). 

5  Strategy  Language 

Informally,  a  BTA  strategy  is  a  guiding  principle  for  annotation.  Known  strategies  include  uniform  analysis 
and  pointwise  analysis.  Our  aim  is  to  specify  a  high-level  ‘strategy  language’  which  may  be  used  to  control  a 
binding-time  analysis.  The  ambition  is  that  the  language  be  simple  while  offering  a  large  design  space  allowing 
to  compare  the  relative  strength  of  different  BTA  strategies. 

Formally,  we  define  a  strategy  to  be  a  criterion  for  being  well-formed  (wit.  the  strategy).  For  instance,  an 
annotation  is  well-formed  wrt.  the  uniform  BTA  strategy  if  and  only  if  every  variable  has  the  same  annotation 
in  all  bt-stores  in  the  annotation.  In  this  paper,  all  strategies  are  of  the  form 

yx€X.'i{pJ),{p',/3')€Ann: 

S{x,p,p',  ^,  0')^  ^{x)  =  D 

where  the  predicate  S  can  take  many  forms.  We  will  identify  a  strategy  with  the  predicate  S  that  defines  it.  We 
implicitly  assume  that  all  annotations  respect  the  congruence  rules  of  the  language,  i.e.  we  implicitly  reQuire 
Ann  C  polymax{P,^o)-  For  convenience,  we  omit  the  parameters  of  a  predicate,  as  in  the  definitions  in  Fig.  3. 
Regard  the  definition  of  Suniform-  This  predicate  defines  a  strategy  that  allows  only  one  annotation  for  each 
variable  in  the  source  program.  The  predicate  is  so  simple  that  it  does  not  need  to  refer  to  p  or  p'. 

To  see  what  this  strategy  means,  consider  the  Monitor  program.  A  polyvariant  annotation  is  given  in  Fig.  4. 
This  annotation  is  not  well-formed  wrt.  Suniform  since  Val  has  more  than  one  annotation.  More  formally, 
choosing  ,  ’ 

a:  =  Val;  (p,^)  =  (13,(5,5,D,5));  (p',/3')  =  (13,(5,D,D,S')) 

we  evidently  get  a  counterexample  to  Suniform-  We  say  that  x  and  (p,^)  form  a  violation  of  the  strategy.  Of 
course,  if  an  annotation  is  not  well-formed  wrt.  some  strategy  S,  a  violation  of  S  must  exist. 

A  natural  annotation  that  does  satisfy  the  uniformity  constraint  is  the  set 

{(p,{5,T>,T>,S'))  |pe  {10,11,12,13,14}}, 

which  is  also  the  one  that  we  would  expect  as  output  of  a  uniform  BTA.  Note,  however,  that  classifying  all 
variables  dynamic  at  all  program  points  is  an  annotation  that  is  also  (trivially)  well-formed  wrt.  Suniform-  This 
annotation  will  be  well-formed  wrt.  any  strategy. 

Another  example  of  a  well-known  strategy  is  Spointwiae  which  is  also  defined  in  Fig.  3.  It  is  obtained  by 
applying  the  uniform  strategy  to  individual  program  points,  merging  bt-stores  only  if  different  ones  occur  at 
a  single  point  in  the  program.  This  strategy  forces  a  monovariant  (but  not  necessarily  uniform)  annotation 
of  all  variables.  Finally,  as  we  have  implicitly  required  all  annotations  to  obey  the  congruence  rules  of  the 
programming  languap,  we  get  a  maximally  polyvariant  strategy  by  adding  no  further  requirements. 

The  authors  have  implemented  a  maximally  polyvariant  PolyMax  function  for  a  non-trivial  subset  of  Fortran— 
the  subset  of  the  FSpec  partial  evaluator  [12].  The  algorithm  builds  upon  a  maximally  polyvariant  BTA  as 
defined  in  Sect.  3. 


6  An  Example  Strategy 

To  illustrate  our  method,  we  show  a  new  strategy  that  can  be  modeled  in  our  framework.  It  is  characterized  by 
separate  treatment  of  different  language  constructs,  e.g.  conditionals,  loops  and  procedures. 
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Source  code 

Residual  code  of  eval  ( (2+3) +x) 

10:  PROCEDURE  eval(E): 

(*  E  =  (2+3) +x  ♦) 

11:  CASE  E.op: 

C*  GlobS  =0  *) 

12:  'cnst:  RETURH  E.val; 

(*  LocS  and  St  are  dynamic.  ♦) 

13:  ,’var  :  RETURN  lookupfE.id) ; 

14:  ’+  :  RETURN  eval(E.Lexp)+ 

eval(E.Rexp) ; 

100:  COMMON  LocS, St; 

101:  INTEGER  Cur; 

20:  PROCEDURE  lookup (Id): 

102:  Cur:=LocS; 

21:  COMMON  GlobS, LocS, St; 

103:  WHILE  (St  [Cur]  .  idy^  ’  x)  DO 

22:  INTEGER  Cur; 

104:  IF  (St [Cur] =’ end) 

23:  Cur:=LocS; 

105:  THEM  Cur:=0; 

24:  WHILE  (St  [Cur]  .  id^^Id)  DO 

106:  ELSE  Cur:=Cur+l; 

25:  IF  (St [Cur] => end) 

107:  ENDWHILE 

26:  THEN  Cur:=GlobS: 

108 :  RETURN  5+St [Cur] . val ; 

27:  ELSE  Cur:=Cur+l; 

28:  ENDWHILE 

29 :  RETURN  St [Cur] . val ; 

30;  END; 

Fig.  5.  Specialization  of  an  interpreter  fragment  using  the  example  strategy. 

The  idea  is  to  minimize  code  explosion  in  the  residual  program  while  being  robust  wrt.  procedure  inlining^  a 
feature  that  is  not  currently  achieved  by  any  system  implementing  polyvariant  procedure  calls  for  an  imperative 
language.  We  also  wish  to  allow  polyvariance  elsewhere  as  long  as  it  can  only  lead  to  code  explosion  in  the 
annotated  program  -  not  the  residual  program.  Towards  this  end,  we  decree  that  loop  entry  points  may  only  be 
annirtated  polyvariantly  if  the  test-expression  (i.e.  the  loop  condition)  is  static,  in  which  case  only  one  branch 
will  be  chosen  by  the  specializer  (leaving  the  other  branch  as  dead  code  in  the  annotated  program).  We  denote 
by  Vioopentry  the  Set  of  program  points  that  constitute  loop  entries.  The  new  strategy  is  defined  by 


^example  =  P  G  Vioopentry  A  ^{test{p))  =  D  A  Spointwise 

shorthand  for  stating  that  the  test  expression  of  the  loop  starting  at  p  is  dynamic 
in  The  above  strategy  will  not  always  prevent  code  explosion,  and  it  does  not  guarantee  termination  of  the 
specialization  phase.  However,  it  demonstrates  that  reasonable  heuristics  can  be  simple  to  phrase. 

An  example  where  this  strategy  turns  out  to  be  useful  is  shown  in  Fig.  5.  The  source  program  is  a  fragment 
of  an  mterpreter  for  a  Fortran-like  language  with  one  local  and  one  global  scope.  Beside  the  input  expression 
the  position  of  the  global  scope  in  the  store  is  also  statically  known.  However,  the  store  itself  and  the  position 
01  the  local  scope  in  the  store  are  dynamic. 

The  reader  may  convince  himself  that  a  uniform  BTA  will  not  achieve  satisfactory  specialization  in  this 
example.  As  demonstrated  [4]  m  a  similar  case,  the  return  value  of  eval  will  be  considered  dynamic,  disallowing 
fell  evaluation  of  2  -f-  3.  On  the  other  hand,  using  a  maximally  polyvariant  BTA,  we  run  into  a  different  problem. 

t  e  WHILE-loop  of  procedure  lookup,  there  is  a  possibility  of  variable  Cur  turning  static  (by  assigning  to 
It  the  value  of  GlobS).  This  possibility  will  be  explored  by  the  specializer.  However,  since  Cur  increases  under 
dynamic  control,  specialization  will  run  into  an  infinite  loop. 

Now  consider  our  example  strategy.  Because  of  the  polyvariant  procedure  annotation,  (2  +  3)  can  be  com¬ 
pletely  evaluated.  Since  the  (dynamically  controlled)  WHILE-loop  must  be  annotated  monovariantly.  Cur  will 
always  be  considered  dynamic  and  we  avoid  infinite  specialization.  Thus,  we  avoid  both  problems  and  obtain 
useful  residued  code. 


7  Related  Work 

Few  attempts  have  been  made  to  examine  different  BTA  strategies.  Notable  exceptions  are  [6,2]  who  developed 
a  poly  variant  BTA  for  a  higher-order  applicative  language  and  [13]  who  implemented  a  polyvariant  BTA  for  the 
Similix  partial  evaluator.  Another  approach  was  suggested  in  [4]  where  polyvariance  is  achieved  by  instrumenting 

programs  with  explicit  bt-values  and  performing  partial  evaluation  in  two  passes;  [14]  used  the  interpretive 
approach.  ^ 

^  That  is,  treating  both  procedure  entry  and  exit  fully  polyvariantly. 
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8  Conclusion 

Our  goal  was  to  develop  the  foundations  for  an  adaptive  approach  to  binding-time  analysis  which  is  flexible 
and  powerful  enough  to  study  the  impact  of  binding-time  strategies  in  a  realistic  context.  We  advocate  that 
partial  evaluation  systems  be  built  that  allow  flexibility  in  the  BTA  instead  of  hard-coding  a  single  strategy  on 
pragmatic  grounds.  We  showed  that  different  BTA  strategies  drastically  influence  of  the  quality  of  generated 
programs.  The  strategy  language  we  developed  allows  us  to  catalog  and  design  different  BTA  strategies. 
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Abstract.  We  present  an  approach  to  software  verification  by  program  inversion,  exploiting  recent  progress 
in  the  field  of  automatic  program  transformation,  partial  evaluation  and  abstract  interpretation.  Abstrac¬ 
tion-based  partial  deduction  can  work  on  infinite  state  spaces  and  can  also  provide  finite  representations 
of  infinite  solution  sets.  We  illustrate  the  potential  of  this  approach  for  infinite  model  checking  of  safety 
properties.  Our  claims  are  substantiated  by  several  computer  experiments. 


1  Introduction 

Modern  computing  applications  increasingly  require  software  and  hardware  systems  that  are  extremely  reliable. 
Unfortunately,  current  validation  techniques  are  often  unable  to  provide  high  levels  of  assurance  of  correctness 
either  due  to  the  size  and  complexity  of  these  systems,  or  because  of  fundamental  limitations  in  reasoning  about 
a  given  system.  This  paper  examines  the  latter  point  showing  that  abstraction-based  partial  deduction  can  serve 
as  a  powerful  analytical  tool.  This  has  several  advantages  in  comparison  with,  e.g.,  standard  logic  programming. 
Among  others,  it  as  the  ability  to  form  recursively  defined  answers  and  can  also  be  used  for  inversion  checking 
and  program  verification. 

We  are  able  to  port  these  inversion  capabilities  to  other  languages  via  interpretive  definitions.  This  means 
that  a  wide  class  of  different  verification  tasks  can  be  analyzed  in  a  common  framework  using  a  set  of  uniform 
transformation  techniques.  We  examine  the  potential  for  infinite  model  checking,  and  support  our  claims  by 
several  computer  experiments. 


2  Inversion,  Partial  Deduction,  and  Interpreters 


\Vhile  direct  computation  is  the  calculation  of  the  output  of  a  program  for  a  given  input,  inverse  computation 
is  the  calculation  of  the  possible  input  of  a  program  for  a  given  output.  Consider  the  familiar  append  program, 
it  can  be  run  forwards  (to  concatenate  two  lists)  and  backwards  (to  split  a  list  into  sublists).  Advances  in  this 
direction  have  been  made  in  logic  programming,  based  on  solutions  emerging  from  logic  and  proof  theory. 

However,  inversion  problems  are  not  restricted  to  logic  languages.  Reasoning  about  the  correctness  of,  say,  a 
software  specification,  one  may  need  to  verify  whether  and  how  a  critical  state  can  be  reached  from  any  earlier 
state.  The  key  idea  is  this:  to  show  that  a  given  system  satisfies  a  given  specification— representing  a  safety 
property  start  with  the  bad  states  violating  the  specification,  work  backwards  and  show  that  no  initial  state 
leads  to  such  a  bad  state. 


The  relationship  between  abstract  interpretation  and  program  specialisation  has  been  observed  and  for¬ 
mal  frameworks  supporting  this  idea  have  been  developed  [6, 10,9].  Abstraction-based  partial  deduction  (APD) 
combines  these  two  approaches  and  can  thereby  obtain  specialisation  and  analysis  which  are  outside  the  reach 
of  either  method  alone  [12, 11].  It  was  shown  that  program  specialisation  combined  with  abstract  interpreta¬ 
tion  can  vastly  improve  the  power  of  both  techniques  (e.g.,  going  beyond  regular  approximations  or  set-based 
analysis)  [12]. 

Language-independence  of  pro^am  transformation  can  be  achieved  through  the  interpretive  approach  [18, 
7, 1]:  an  interpreter  serves  as  mediator  between  a  (domain-specific)  language  and  the  language  for  which  the 
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Fig.  1.  Abstraction-based  partial  deduction  ab-spec  applied  to  Petri-nets,  7r-calculus,  and  functional  programs  via 
interpretive  language  definitions. 


program  transformer  is  defined.  Efficient  implementations  of  the  corresponding  tools  can  be  achieved  automati¬ 
cally  (a  notable  example  are  the  Futamura  projections) .  Work  on  porting  inverse  computation  to  new  languages 
includes  the  inversion  of  imperative  programs  by  treating  their  relational  semantics  as  logic  programs  [15]. 

Our  Approach  The  approach  we  will  pursue  in  this  paper  is  twofold.  First,  we  apply  the  power  of  APD  on 
inverse  computation  tasks.  Instead  of  enumerating  a  list  of  substitutions,  we  produce  a  new  logic  program  by 
APD  which  can  be  viewed  as  model  of  the  original  program  instantiated  to  the  given  query.  The  transformation 
will  (hopefully)  derive  a  much  simpler  program  (such  as  p  fail),  but  this  method  has  also  the  ability  to 
form  recursively  defined  programs.  Second,  we  use  the  interpretive  approach  to  achieve  language-independence. 
We  will  thereby  be  able  to  apply  inversion  capabilities  provided  by  APD  to  different  language  paradigms,  such 
as  Petri-nets  and  the  rr-calculus,  without  having  to  write  tools  (illustrated  in  Fig.  1). 

To  put  these  ideas  to  a  trial,  we  use  the  ECCB  logic  program  specializer  [12, 13] — employing  advanced  control 
techniques  such  as  characteristic  trees  to  guide  the  specialisation  process — coupled  with  an  abstract  interpretation 
technique,  as  described  in  [12].  (A  more  detailed  technical  account  is  beyond  the  scope  of  this  extended  abstract; 
the  interested  reader  will  find  a  complete  description  in  [12, 13].)  This  APD-system  does  not  yet  implement  the 
full  power  of  [12, 11],  but  it  will  turn  out  to  be  sufficiently  powerful  for  our  purposes.  Indeed,  as  we  will  show 
below,  it  will  give  us  a  novel  technique  for  powerful  inverse  computation  and  inversion  checking. 

3  Advanced  Inversion  Tasks  for  Logic  Programs 

To  illustrate  three  questions  about  a  software  requirement  specification  relying  on  solving  inversion  problems, 
let  us  consider  a  familiar  example:  exponentiation  z  =  oi  natural  numbers. 

1.  Existence  of  solution?  Given  output  state  z  (e.g.  2  =  3),  does  there  exist  an  input  state  x,y  with  y  >  1 
that  gives  raise  to  z?  Answer:  state  2  =  3  can  never  be  reached.  Observe  that  here  we  are  not  interested 
in  the  values  oi  x,y,  we  are  just  interested  whether  such  values  exists.  We  will  call  such  a  setting  inversion 
checking. 

2.  Finiteness  of  solution?  Given  output  state  2  (e.g.  2  =  4),  is  there  a  finite  number  of  input  states  x,y  can 
give  raise  to  z?  Answer:  only  two  states  (x  =  i,y  =  1  and  x  =  2,y  =  2)  lead  to  2  =  4. 

3.  Finite  description  of  infinite  solution?  Given  output  state  2  (e.g.  2=1),  can  an  infinite  set  of  input  states 
be  described  in  a  finite  form?  Answer:  any  input  state  with  y  =  0  leads  to  2  =  1,  regardless  of  x. 

Example  1.  We  show  that  all  questions  posed  above  can  be  answered  with  abstraction-based  partial  deduction. 
Consider  a  logic  program  encoding  exponentiation  of  natural  numbers  represented  by  terms  of  type  r  =  0  |  s  (r) . 

exp (Base , 0 , s (0) ) . 

exp(Base,s(Exp) ,Res)  exp(Base,Exp.BE) ,mul(BE,Basa.Res)  . 
muKO.X.O). 

inul(s(X),Y.Z)  mul(X.Y.XY),plus(XY,y,Z). 
plus(0,X,X) . 

plus(s(X),Y.s(Z))  plus(X,Y,Z) . 

1.  Existence  of  solution.  Imeviing  the  program  for  x^  -  3,  y  >  I,  that  is  specialising  exp/2  wrt.  goal 
exp(X,s(s(Y))  ,s(s(s(0)))),  produces  an  empty  program:  no  solution  exists. 

2.  Finiteness  of  solution.  Inverting  x^  =  4,  that  is  by  specialising  exp/2  wrt.  goal  exp(X,Y,s(s(s(s(0))))) 
produces  a  program  in  which  the  two  solutions  a;  =  4,y  =  1  and  x  =  2,y  —  2  are  explicit: 


exp _ l(s(s(s(s(0))))  ,s(0))  . 

exp _ 1  (s  (s  (0)  )  ,  s  (s  (0)  )  )  . 
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3.  Finite  representation  of  infinite  solution.  Finally,  inverting  =  1  can  be  solved  by  specialising  exp/2  wrt. 
goal  exp(X,Y,s(0)).  The  result  is  a  recursive  program;  infinitely  many  solutions  were  found  (a;°  and  for 
any  x  and  y)  and  described  in  a  finite  way.^  This  is  possible  in  our  approach,  but  not  in  conventional  logic 
programming,  because  we  generate  (recursive)  programs  instead  of  enumerating  an  (infinite)  list  of  answers. 

exp__l(X1.0) . 

exp _ l(s(0) ,s(Xl))  exp.conj _ 2(X1). 

exp_conj _ 2(0). 

exp_conj__2(s(Xl))  exp_conj__3(Xl) . 

exp_conj _ 3(0) . 

exp_conj _ 3(s(Xl))  exp_conj _ 3(X1). 

To  conclude,  abstraction-based  partial  deduction  can  successfully  invert  programs  in  ways  not  possible  with  any 
of  the  existing  approaches  to  inversion. 

Example  2.  As  a  more  practical  application,  take  the  following  program: 
pairl([]). 

pairl([A|X])  oddl(X)  .  delete (X,  [X IT]  ,T)  . 

oddKCAlX]);-  pairl(X) .  delete(X,  [YlT]  ,  [YjDT]) X\=Y, delete (X, T, DT)  . 

One  might  want  to  verify  the  property  that  deleting  an  element  from  a  pair  list  will  not  result  in  a  pair  list. 
This  can  be  translated  into  requiring  that  the  following  predicate  always  fails: 
error (X,L)  pairl(L) .delete (X,L,DL) ,pairl(DL) . 

which  can  be  deduced  by  our  APD-system:  error_.l(x,L)  fall.  / 

4  Case  Study;  Inversion  and  Infinite  Model  Checking 

Recent  years  have  seen  considerable  growth  [5]  in  the  application  of  model  checking  [4,2]  techniques  to  the 
validation  and  verification  of  correctness  properties  of  hardware,  and  more  recently  software  systems.  The 
method  is  to  model  a  hardware  or  software  system  as  a  finite,  labelled  transition  system  (LTS)  which  is  then 
exhaustively  explored  to  decide  whether  a  given  specification  holds  for  all  reachable  states.  One  can  even  use 
tabling-based  logic  programming  as  an  efl^cient  means  of  performing  explicit  model  checking  [14].  However, 
many  software  systems  cannot  be  modelled  by  a  finite  LTS  (or  ,  similar  system)  and  recently  there  has  been  a 
lot  of  effort  to  enable  infinite  model  checking  (e.g.,  [17]).  We  argue  that  inverse  computation  in  general,  and  our 
■^PD'tfichnique  of  Section  2  in  particular,  has  a  lot  to  offer  for  this  avenue  of  research: 

-  We  can  model  a  system  to  be  verified  as  a  program  (possibly  using  metacomputation  by  means  of  an 
interpreter) .  This  obviously  includes  finite  LTS  but  also  allows  to  express  systems  with  an  infinite  number 
of  states. 

-  Model  checking  of  safety  properties  then  amounts  to  inversion  checking:  we  prove  that  a  specification  holds 
by  showing  that  there  exists  no  trace  (the  input  argument)  which  leads  to  an  invalid  state. 

-  To  be  successful,  infinite  model  checking  requires  refined  abstractions  (a  key  problem  mentioned  in  [5]).  The 
control  of  generalisation  of  APD  provides  just  that  (at  least  for  the  examples  we  treated  so  far)!  In  essence, 
the  specialisation  component  of  APD  performs  a  symbolic  traversal  of  the  state  space,  thereby  producing  a 
finite  representation  of  it,  on  which  the  abstract  interpretation  performs  the  verification  of  the  specification. 
Consider  the  Petri  net  in  Figure  2  that  models  a  single  process  which  may  enter  a  critical  section  (cs)  the 

access  to  which  is  controlled  by  a  semaphore  (sema).  The  Petri  net  can  be  encoded  directly  as  logic  program. 
To  do  this  we  use  an  interpreter  trace/3,  where  the  object-level  Petri  net  is  encoded  via  trans/3  facts  and  the 
trace/3  predicate  checks  for  enabled  transitions  and  fires  them.  The  initial  marking  of  trace/3  in  start/3  is  1 
to  en  in  the  semaphore  (sema),  0  tokens  in  the  reset  counter  (c),  no  processes  in  the  critical  section  (cs)  and  no 
processes  m  the  final  pl^e  (y).  There  may  be  X  processes  in  the  initial  place  (x).  Again,  numbers  are  represented 
by  terms  of  type  t  =  0  |  s(r) .  More  processes  can  be  modelled  if  we  increase  the  number  of  tokens  in  the  initial 
place  (x).  Forward  execution  of  the  Petri  net  is:  given  an  initial  value  for  X  and  a  sequence  of  transitions  trace 
determine  the  marking(s)  that  can  be  reached. 

Let  us  now  try  to  check  a  safety  property  of  the  above  Petri  net,  namely  that  it  is  impossible  to  reach  a 
marking  where  two  processes  are  in  their  critical  section  at  the  same  time.  Clearly,  this  is  an  inversion  task: 
^ven  a  marking  try  to  find  a  trace  that  leads  to  it.  More  precisely  we  want  to  do  inversion  checking,  as  the 
desired  outcome  is  to  prove  that  no  inverse  exists. 

By  a  better  post-processing  it  is  possible  to  further  improve  the  residual  program. 
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start(Trace,X,ReacliableHarking) 

trace (Trace, [X,s(0) ,0,0,0] ,ReachableMarking) . 
trace ([]  ,Marklng,Marking) . 
trace ( [Action  I  As] ,InMarking,OutMarking) 

trans (Action, InMarking, Ml) ,trace(As,Ml,OutMarking) . 
trans(enter_cs,  [s(X)  ,s(Seina)  ,CritSec,Y,C]  ,  [X,Sema,s(CritSec)  ,Y,C])  . 
trcins(exit_cs,  [X,Sema,s(CritSec)  ,Y,C]  ,  [X,s(Se]na)  ,CritSec,s(Y)  ,C])  . 
trans (restart, [X,Sema,CritSec,s(Y) ,C] , [s(X) ,Sema,CritSec,Y,s(C)]) . 

Fig.  2.  Petri  net  with  a  single  semaphore  and  its  encoding  as  logic  program. 

Example  3.  Inverting  the  Petri  net  by  specialising  the  interpreter  in  Figure  2  wrt  the  query 
start(Tr.s(0),[X,S,s(s(CS)),Y,C]) 
we  obtain  the  following  program: 

start(Tr,s(0).[X3,X4,s(s(X5)),X6,X7])  fail. 

This  inversion  task  cannot  be  solved  by  PROLOG  (or  even  XSB-Prolog  [3,16]  with  tabling),  even  when 
adding  moding  or  delay  declarations.  Due  to  the  counter  (c)  we  have  to  perform  infinite  model  checking  which 
in  turn  requires  abstraction  and  symbolic  execution.  Both  of  these  are  provided  by  our  abstraction-based  partial 
deduction  approach  described  in  Section  2. 

Similarly,  one  can  prove  the  safety  property  regardless  of  the  number  of  processes,  i.e.,  for  any  number  of 
tokens  in  the  initial  place  (x).  When  we  specialise  the  interpreter  of  Figure  2  for  the  query  unsafe(x,s(0)  ,o,o,o) 
we  get  (after  2  iterations  each  of  the  specialisation  and  abstract  interpretation  compontents  of  ECCe): 
start(Tr, Processes, [X3,X4,s(s(X5)) ,X6,X7])  j-fail. 

5  Porting  to  other  Languages  and  Paradigms 

We  can  apply  the  power  of  our  APD-approach,  along  with  its  capabilities  for  inversion  and  verification  [8] ,  to  the 
TT-calculus,  simply  by  writing  an  interpreter  for  it  in  logic  programming.  We  have  also  successfully  ported  our 
inverse  computation  and  verification  tool  to  a  functional  language  via  an  interpreter  (omitted  from  extended 
abstract).  Apart  from  highlighting  the  power  of  our  approach  it  is  further  computational  evidence  for  the 
feasibility  of  the  method  of  porting  tools  via  metacomputation.  We  conjecture  that  the  same  approach  can  be 
used  for  verification  tasks  in  other  related  domains. 

6  Conclusion  and  Assessment 

We  presented  an  approach  to  program  inversion,  exploiting  progress  in  the  field  of  automatic  program  transfor¬ 
mation,  partial  deduction  and  abstract  interpretation.  We  were  able  to  port  these  inversion  capabilities  to  other 
languages  via  interpretive  definitions.  We  examined  the  potential  for  infinite  model  checking  of  safety  properties, 
and  supported  our  claims  by  computer  experiments.  We  believe,  by  exploiting  the  connections  between  software 
verification  and  automatic  program  specialisation  one  may  be  able  to  significantly  extend  the  capabilities  of 
analytical  tools  that  inspect  the  input/output  behaviour. 

The  emphasis  was  on  novel  ways  of  reasoning  rather  than  efficiency  and  large  scale  applications.  In  principle, 
it  is  possible  to  extend  our  approach  to  verify  larger,  more  complicated  infinite  systems.^  As  with  all  automatic 
specialisation  tools,  there  are  several  points  that  need  to  be  addressed:  allow  more  generous  unfolding  and 
polyvariance  (efficiency,  both  of  the  specialisation  process  and  the  specialised  program,  are  less  of  an  issue  in 
model  checking)  to  enable  more  precise  residual  programs  and  implement  the  full  algorithm  of  [11]  which  allows 
for  more  fine  grained  abstraction  and  use  BDD-like  representations  whenever  possible.  Currently  we  can  only 
verify  safety  properties  (i.e.,  that  no  bad  things  happen)  and  not  liveness  properties  (i.e.,  that  good  things  will 
eventually  happen).  The  latter  might  be  feasible  by  a  more  sophisticated  support  for  the  negation. 

^  Larger  systems  have  been  approached  with  related  techniques  as  a  preprocessing  phase  [9].  However,  their  purpose  is 
to  reduce  the  state  space  rather  than  provide  novel  ways  of  reasoning. 
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Abstract.  The  current  state  of  the  art  for  ensuring  finite  unfolding  of  logic  programs  consists  of  a  number 
of  online  techniques  where  unfolding  decisions  are  made  at  specialisation  time.  Introduction  of  a  static 
termination  analysis  phase  into  a  partial  deduction  algorithm  permits  unfolding  decisions  to  be  made  offline, 
before  the  actual  specialisation  phase  itself.  This  separation  improves  specialisation  time  and  facilitates  the 
automatic  construction  of  compilers  and  compiler  generators.  The  main  contribution  of  this  paper  is  how 
this  separation  may  be  achieved  in  the  context  of  logic  programming,  while  providing  non-trivial  support 
for  partially  static  datastructures. 

The  paper  establishes  a  solid  link  between  the  fields  of  static  termination  analysis  and  partial  deduction 
enabling  existing  termination  analyses  to  be  used  to  ensure  finiteness  of  the  unfolding  process.  This  is 
the  first  ofiline  technique  which  allows  arbitrarily  partially  instantiated  goals  to  be  sufficiently  unfolded  to 
achieve  good  specialisation  results.  Furthermore,  it  is  demonstrated  that  an  offline  technique  such  as  this 
one  can  be  implemented  very  efficiently  and,  surprisingly,  yield  even  better  specialisation  than  a  (pure) 
online  technique.  It  is  also,  to  our  knowledge,  the  first  offline  approach  which  passes  the  KMP  test  (i.e., 
obtaining  an  efficient  Knuth-Morris-Pratt  pattern  matcher  by  specialising  a  naive  one). 


Keywords:  Partial  evaluation,  mixed  computation,  and  abstract  interpretation,  Program  transformation  and 
specialisation,  Logic  programming,  Partial  deduction.  Termination. 

1  Introduction 

Control  of  partial  deduction — a  technique  for  the  partial  evaluation  of  pure  logic  programs — is  divided  into  two 
levels.  The  local  level  guides  the  construction  of  individual  SLDNF-trees  while  the  global  level  manages  the  forest, 
determining  which,  and  how  many  trees  should  be  constructed.  Each  tree  gives  rise  to  a  specialised  predicate 
definition  in  the  final  program  so  the  global  control  ensures  a  finite  number  of  definitions  are  generated  and 
also  controls  the  amount  of  polyvariance.  The  local  control  on  the  other  hand  determines  what  each  specialised 
definition  will  look  like. 

Techniques  developed  to  ensure  finite  unfolding  of  logic  programs  [9, 37, 36]  have  been  inspired  by  the  various 
methods  used  to  prove  termination  of  rewrite  systems  [17, 16].  Whilst,  by  no  means  ad  hoc,  there  is  little  direct 
relation  between  these  techniques  and  those  used  for  proving  termination  of  logic  programs  (or  even  those 
of  rewrite  systems).  This  means  that  advances  in  the  static  termination  analysis  technology  do  not  directly 
contribute  to  improving  the  control  of  partial  deduction.  The  work  of  this  chapter  aims  to  bridge  this  gap. 

Moreover,  the  control  described  in  [9, 37, 36]  as  well  as  the  more  recent  [45, 29]  are  inherently  online,  meaning 
that  they  are  much  slower  than  offline  approaches  and  that  they  are  not  based  on  a  global  analysis  of  the 
program’s  behaviour  which  enables  control  decisions  to  be  taken  before  the  actual  specialisation  phase  itself. 

Offline  approaches  to  local  control  of  partial  deduction  on  the  other  hand  [40, 22, 23, 10]  have  been  very 
limited  in  other  respects.  Specifically,  each  atom  in  the  body  of  a  clause  is  marked  as  either  reducible  or  non¬ 
reducible.  Reducible  atoms  remain  are  always  unMded  while  non-reducible  atoms  on  the  other  hand  are  never 
unfolded.  Whilst  this  approach  permits  goals  to  be  unfolded  at  normal  execution  speed,  it  can  unduly  restrict  the 
amount  of  unfolding  which  takes  place  with  a  detrimental  effect  on  the  resulting  specialised  program.  Another 
problem  of  [40,23]  is  that  it  classifies  arguments  either  as  static  (known  at  specialisation  time)  or  dynamic 
(unknown  at  specialisation  time).  This  division  is  too  coarse,  however,  to  allow  refined  unfolding  of  goals 
containing  partially  instantiated  data  where  some  parts  of  the  structure  are  known  and  others  unknown.  Such 
goals  are  very  common  in  logic  programming,  and  the  key  issue  which  needs  to  be  considered  is  termination.  A 
partial  solution  to  this  problem  has  been  presented  in  [10],  but  it  still  sticks  with  the  limited  unfolding  mentioned 
above  and  can  “only”  handle  a  certain  class  of  partially  instantiated  data  (data  bounded  wrt  some  semi-linear 
norm). 
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A  Sonic  Approach  This  paper  proposes  a  flexible  solution  to  the  local  termination  problem  for  offline  partial 
deduction  of  logic  programs,  encompassing  the  best  of  both  worlds.  Based  on  the  cogen  approach^  for  logic  pro¬ 
grams  [23],  the  construction  of  a  generating  extension  will  be  described  which  “compiles  in”  the  local  unfolding 
rule  for  a  program  and  is  capable  of  constructing  maximally  expanded  SLDNF-trees  of  finite  depth. 

1  he  technique  builds  directly  on  the  work  of  [38]  which  describes  a  method  for  ensuring  termination  of  logic 
programs  with  delay.  The  link  here  is  that  the  residual  goals  of  a  deadlocked  computation  are  the  leaves  of  an 
incomplete  SLD-tree.  The  basic  idea  is  to  use  static  analysis  to  derive  relationships  between  the  sizes  of  goals 
and  the  depths  of  derivations.  This  depth  information  is  incorporated  in  a  generating  extension  and  is  used  to 
accurately  control  the  unfolding  process.  At  specialisation  time  the  sizes  of  certain  goals  are  computed  and  the 
maximum  depth  of  subsequent  derivations  is  fixed  according  to  the  relationships  derived  by  the  analysis.  In 
this  way,  termination  is  ensured  whilst  allowing  a  flexible  and  generous  amount  of  unfolding.  Section  3  reviews 
the  work  of  [38]  and  shows  how  it  can  be  used  directly  to  provide  the  basis  of  a  generating  extension  which 
allows  finite  unfolding  of  bounded  goals.  A  simple  extension  to  the  technique  is  described  in  Section  4  which 
also  permits  the  safe  unfolding  of  unbounded  goals. 

This  is  the  first  offline  approach  to  partial  deduction  which  is  able  to  successfully  unfold  arbitrarily  partially 
instantiated  (i.e.  unbounded)  goals.  In  fact,  it  is  demonstrated  that  the  method  can,  surprisingly,  yield  even 
better  specialisation  than  (pure)  online  techniques.  In  particular,  some  problematic  issues  in  unfolding,  notably 
unfolding  under  a  coroutining  computation  rule  and  the  back  propogation  of  instantiations  [36],  can  be  easily 
handled  within  the  approach  (for  further  details  see  [39]).  Furthermore,  it  is  the  first  offline  approach  which 
passes  the  KMP  test  (i.e.,  obtaining  an  efficient  Knuth-Morris-Pratt  pattern  matcher  by  specialising  a  naive 
one),  as  demonstrated  by  the  extensive  experiments  in  Section  6. 

An  analysis  which  measures  the  depths  of  derivations  may  be  termed  a  sounding  analysis.  Section  5  describes 
how  such  an  analysis  can  be  based  on  existing  static  termination  analyses  which  compute  level  mappings  and 
describes  how  the  necessary  depths  may  be  obtained  from  these  level  mappings.  Unfolding  based  on  a  sounding 
analysis  then,  is  the  basis  of  sonic  partial  deduction. 


2  Preliminaries 


Familiarity  with  the  basic  concepts  of  logic  programming  and  partial  deduction  is  assumed  [34,35].  A  level 
mapping  (resp.  norm)  is  a  mapping  from  ground  atoms  (resp.  ground  terras)  to  natural  numbers.  For  an  atom 

r  l  I  An  atom  A  is  (un)bounded  wrt  |.|  if  A,  ,  is 

(injhnite  [13].  For  this  paper,  the  notion  of  level  mapping  is  extended  to  non-ground  atoms  by  defining  for 

^  similarly  for  norms.  The  norm  returns  the  length  of  the  list  t.  A  list  t  is  rigid 

I  rrli -Ti  A  Li  r  "  u  h'  i  c  :  Ai, . . . ,  A„  is  recurrent  if  for  every  grounding  substitution  6  for  c, 

>  \Ai9\  for  all  t  G  [l,n].  ’ 


3  Unfolding  Bounded  Atoms 

A  fundaments  problem  in  adapting  techniques  from  the  termination  literature  for  use  in  controlling  partial 
deduction  IS  that  the  various  analyses  that  have  been  proposed  (see  [13]  for  a  survey)  axe  designed  to  prove  Ml 
termination  for  a  given  goal  and  program,  in  other  words  guaranteeing  finiteness  of  the  complete  SLDNF-tree 
constructed  for  the  goal.  For  example,  consider  the  goal  ^  Flatten([x,  y,  z],  w)  and  the  program  Flatten  consisting 
01  the  clauses  appi,  app2,  flati  and  flat2.  ^ 


flati  Flatten([],  []). 

flat^  Flatten([e|x],  r)  e-  Append(e,  y,  r)  A  Flatten(x,  y). 
app^  Append(0,  ><)■ 

app2  Append([u|x],  y,  [u|z])  e-  Append(x,  y,  z). 


A  typical  static  termination  analysis  would  (correctly)  fail  to  deduce  termination  for  this  program  and  goal 
Most  analyses  can  infer  that  a  goal  of  the  form  ^  Flatten(x.  y)  will  terminate  if  x  is  a  rigid  list  of  rigid  lists  or  if 
X  IS  a  rigid  list  and  y  is  a  rigid  list.  In  the  context  of  partial  deduction  however,  such  a  condition  for  termination 

'  Instead  of  trying  to  achieve  a  compiler  generator  (cogen)  by  self-application  [18]  one  writes  the  cogen  directly  [43], 
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will  usually  be  too  strong.  The  problem  is  that  the  information  relating  to  the  goal,  by  the  very  nature  of  partial 
deduction,  is  often  incomplete.  For  example,  the  goal  Flatten ([x,  y,  z],  w),  will  not  terminate  but  the  program 
can  be  partially  evaluated  to  produce  the  following  specialised  definition  of  Flatten/2. 

Flatten([x,  y,  z],  r)  e-  Append(x,  rl,  r  )  A  Append(y,  r2,  rl)  A  Append(z,  [],  r2). 

The  scheme  described  in  [38]  transforms  programs  into  efficient  and  terminating  programs.  It  will  for  instance 
transform  the  non-terminating  program  Flatten  into  the  following  efficient,  terminating  program,  by  adding  an 
extra  depth  parameter. 

flat*  Flatten(x,  y)  ■<—  SetDepth-F(x.  d)  A  Flatten(x,  y,  d). 

DELAY  Flatten(-,  d)  UNTIL  Ground(d). 
flatl  Flatten([],  [],  d)  •<—  d  >  0. 

flat2  Flatten([e|x],  r,  d)  <—  d  >  0  A  Append(e,  y,  r)  A  Flatten(x,  y,  d  —  1). 

app*  Append(x,  y,  z)  -f-  SetDepth^(x,  z,  d)  A  Append(x,  y,  z,  d). 

DELAY  Append(_,  d)  UNTIL  Ground(d). 
appl  Append([],  x,  x,  d)  d  >  0. 

appl  Append([u|x],  y,  [ulz],  d)  -e-  d  >  0  A  Append(x,  y,  z,  d  -  1). 

For  now,  assume  that  the  (meta-level)  predicate  SetDepth.F(x,  d)  is  defined  such  that  it  always  succeeds 
instantiating  the  variable  d  to  the  length  of  the  list  x  if  this  is  found  to  be  rigid, (i.e.,  |x|/e„  =  \x0\ien  for  every 
substitution  9),  and  leaving  d  unbound  otherwise.  Note  that  a  call  to  Flatten/3  will  proceed  only  if  its  third 
argument  has  been  instantiated  as  a  result  of  the  call  to  SetDepth-F(x,  d).  The  purpose  of  this  last  argument  is  to 
ensure  finiteness  of  the  subsequent  computation.  More  precisely,  d  is  an  upper  bound  on  the  number  of  calls  to 
the  recursive  clause  flat^  in  any  successful  derivation.  Thus  by  failing  any  derivation  where  the  number  of  such 
calls  has  exceeded  this  bound  (using  the  test  d  >  0),  termination  is  guaranteed  without  losing  completeness. 
The  predicate  SetDepth  Jt/3  is  defined  in  a  similar  way,  but  instantiates  d  to  the  minimum  of  the  lengths  of  the 
lists  X  and  z,  delaying  if  both  x  and  z  are  unbounded. 

The  main  result  of  [38]  guarantees  that  the  above  program  will  terminate  for  every  goal  (in  some  cases  the 
program  will  deadlock).  Moreover,  given  a  goal  of  the  form  e-  Flatten(x,  y)  where  x-  is  a  rigid  list  of  rigid  lists  or 
where  x  is  a  rigid  list  and  y  is  a  rigid  list,  the  program  does  not  deadlock  and  produces  all  solutions  to  such  a 
goal.  In  other  words,  both  termination  and  completeness  of  the  program  are  guaranteed. 

Since  the  program  is  terminating  for  all  goals,  it  can  be  viewed  as  a  means  of  constructing  a  finite  (possibly 
incomplete)  SLD-tree  for  any  goal.  As  mentioned  above,  it  is  indeed  capable  of  complete  evaluation  but  a  partial 
evaluation  for  bounded  goals  may  also  be  obtained.  Quite  simply,  the  deadlocking  goals  of  the  computation  are 
seen  to  be  the  leaf  nodes  of  an  incomplete  SLD-tree. 

For  example,  the  goal  <e-  Flatten([x,  y,  z],  r)  leads  to  deadlock  with  the  residual  goal  -e-  Append(x,  rl,  r,  dl)  A 
Append(y,  r2,  rl,  d2)  A  Append(z,  Q,  r2,  d3).  Removing  the  depth  bounds,  this  residue  can  be  used  to  construct  a 
partial  evaluation  of  the  original  goal  resulting  in  the  specialised  definition  of  Flatten/2  above. 

The  approach,  thus  far,  is  limited  in  that  it  can  only  handle  bounded  goals.  For  unbounded  goals  the 
unfolding  will  deadlock  immediately  and  it  is  not  possible,  for  example,  to  specialise  ■(-  Flatten([Q,  [a]  j  z],  r)  in  a 
non-trivial  way.  This  strong  limitation  will  be  overcome  in  the  following  sections. 

Finally,  observe  that  in  contrast  to  [8,36]) — our  approach  eliminates  the  need  to  explicitly  trace  direct 
covering  ancestors,  improving  performance  of  the  specialisation  process  and  removing  a  potential  source  of 
programming  errors.  In  addition,  some  problematic  issues  in  unfolding,  notably  unfolding  under  a  coroutining 
computation  rule  and  the  back  propogation  of  instantiations  [36],  can  be  easily  handled  within  the  approach 
(for  further  details  see  [39]). 

4  Unfolding  Unbounded  Atoms 

The  main  problem  with  the  above  transformation  is  that  it  only  allows  the  unfolding  of  bounded  goals.  Often, 
as  mentioned  in  the  introduction,  to  achieve  good  specialisation  it  is  necessary  to  unfold  unbounded  atoms  also! 
This  is  especially  true  in  a  logic  programming  setting,  where  partially  instantiated  goals  occur  very  naturally 
even  at  runtime.  This  capability  may  be  incorporated  into  the  above  scheme  as  follows.  Although  an  atom  may 
be  unbounded,  it  may  well  have  a  minimum  size.  For  example' the  length  of  the  list  [1,2, 3|x]  must  be  at  least 
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three  regardless  of  how  x  may  be  instantiated.  In  fact,  this  minimum  size  is  an  accurate  measure  of  the  size 
of  the  part  of  the  term  which  is  partially  instantiated  and  this  may  be  used  to  determine  an  estimate  of  the 
number  of  unfolding  steps  necessary  for  this  part  of  the  term  to  be  consumed  in  the  specialisation  process.  For 
example,  consider  the  Append/3  predicate  and  the  goal  -h  Append([l,2.3|x],  y,  2).  Given  that  the  minimum  size 
of  the  first  argument  is  three  it  may  be  estimated  that  at  least  three  unfolding  steps  must  be  performed.  Now 
suppose  that  the  number  of  unfolding  steps  is  fixed  at  one  plus  the  minimum  (this  will  usually  give  exactly  the 
required  amount  of  specialisation).  The  transformed  Flatten  program  may  now  be  used  to  control  the  unfolding 
by  simply  calling  <-  Append([l,2,3|x],  y,  z,  3).  The  problem  here,  of  course,  is  that  completeness  is  lost,  since  the 
goal  fails  if  x  does  not  become  instantiated  to  0-  To  remedy  this,  an  extra  clause  is  introduced  to  capture  the 
leaf  nodes  of  the  SLD-tree.  The  Append/3  predicate  would  therefore  be  transformed  into  the  following. 

appl  Append{[|,  x,  x,  d)  e-  d  >  0. 

appl  Append([u|x],  y,  [u|z],  d)  ■(-  d  >  0  A  Append(x,  y,  z,  d  -  1). 

“PPa  Append(x,  y.  z,  d)  -H-  d  <  0  A  Append(x,  y,  2,  .). 

The  call  to  Append/4  in  the  clause  appg  immediately  suspends  since  the  depth  argument  is  uninstantiated. 
The  clause  is  only  selected  when  the  derivation  length  has  exceeded  the  approximated  length  and  the  effect  is 
that  a  leaf  node  (residual  goal)  is  generated  precisely  at  that  point.  For  this  reason,  such  a  clause  is  termed  a 
leaf  generator  in  the  sequel.  Now  for  the  goal  ^  Append([l,2,3|x],  y,  z,  3)  the  following  resultants  are  obtained. 

Append([l,2,3],  y.  [l,2.3|y],  3)  ^ 

Append([l,2,3.u|x’],  y.  [l,2,3.u|z’],  3)  -i-  Append(x’.  y,  2’) 

Observe  that  the  partial  input  data  has  been  completely  consumed  in  the  unfolding  process.  In  fact  in 
this  example,  one  more  unfolding  step  has  been  performed  than  is  actually  required  to  obtain  an  “optimal” 
specialisation,  but  this  is  due  to  the  fact  that  the  goal  has  been  unfolded  non-deterministically.  In  some  cases 
this  non-deterministic  unfolding  may  actually  be  desirable,  but  this  is  an  orthogonal  issue  to  termination  (this 
issue  will  be  re-examined  in  Section  6). 

Furtherinore,  note  that  the  SetDepth  predicates  must  now  be  redefined  to  assign  depths  to  unbounded  atoms 
Also  a  predica,te  such  as  SetDepth  J\(x,  2,  d)  must  be  defined  such  that  d  gets  instantiated  to  the  maximum  of 
the  niinimum  lengths  of  the  lists  x  and  z  to  ensure  a  maximal  amount  of  unfolding.  Note  that  this  maximum 
will  always  be  finite. 


5  Deriving  Depth  Bounds  from  Level  Mappings 

The  above  transformations  rely  on  a  sounding  analysis  to  determine  the  depths  of  derivations  or  unfoldings 
Such  an  analysis  may  be  based  on  exisiting  termination  analyses  which  derive  level  mappings.  To  establish  the 
hnk  with  the  termination  literature  the  depth  argument  in  an  atom  during  unfolding  may  simply  be  chosen  to 
be  the  lew/  of  the  atom  with  respect  to  some  level  mapping  used  in  a  termination  proof.  Whilst,  in  princiole 
a  depth  bourid  for  unfolding  may  be  derived  from  any  level  mapping,  in  practice  this  can  lead  to  excessive 
unfolding  and,  as  a  consequence,  poor  specialisation.  (For  example,  based  on  some  termination  analysis,  an 
atom  might  have  a  level  mapping  of  15,  diminishing  by  5  on  every  recursive  call.  One  could  give  the  atom  a 
depth  of  15,  but  in  this  case  the  value  of  3  would  be  much  more  appropriate,  preventing  over-eager  unfolding.) 

A  number  of  techniques  have  been  devised  to  obtain  accurate  depth  bounds  from  fairly  arbitrary  level 
mappings  derived  from  termination  analyses.  Space  restrictions  prohibit  a  detailed  presentation  here,  but  the 
_ec  niques  are  extremely  simple  to  apply  and  introduce  minimal  overhead  (and  sometimes  none  at  all;  for 
rther  details  see  [39]).  It  is  important  to  note,  however,  that  finiteness  can  always  be  guaranteed;  the  problems 
encoutered  only  relate  to  the  quality  of  the  specialisation  and  this  is  also  dependent  on  the  control  of  determinacy 
Although  this  has  been  touched  upon  in  [19]  this  is  still  a  relatively  unexplored  area  in  the  context  of  partial 
deduction.  Many  of  the  problems  may  disappear  altogether  with  the  right  balance  of  bounded  and  determinate 


6  Experiments  and  Benchmarks 

efficiency  and  POwer  of  the  sdnic  approach,  a  prototype  implementation  has  been  devised  and 
integrated  into  the  ecce  partial  deduction  system  ([27,28,33]).  The  latter  is  responsible  for  the  global  control 
and  code  generation  and  calls  the  sonic  prototype  for  the  local  control.  A  comparison  has  been  made  with  ECCE 
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under  the  default  settings,  i.e.  with  ECCB  also  providing  the  local  control  using  its  default  unfolding  rule  (based 
on  a  determinate  unfolding  rule  which  uses  the  homeomorphic  embedding  relation  <  on  covering  ancestors  to 
ensure  termination).  For  the  global  control,  both  specialisers  used  conjunctive  partial  deduction  ([31,21])  and 
characteristic  trees  ([33]). 


Benchmark 

sonic  -f-  ECCE 

ECCE 

advisor 

0  ms 

33  ms 

applast 

0  ms 

16  ms 

doubleapp 

0  ms 

0  ms 

map. reduce 

0  ms 

17  ms 

map.rev 

0  ms 

34  ms 

match.kmp 

0  ms 

99  ms 

matchapp 

0  ms 

33  ms 

maxlength 

0  ms 

67  ms 

regexp.rl 

0  ms 

383  ms 

relative 

0  ms 

166  ms 

remove 

34  ms 

201  ms 

remove2 

33  ms 

50  ms 

reverse 

16  ms 

33  ms 

rev_acc_type 

0  ms 

32  ms 

rotateprune 

0  ms 

99  ms 

ssupply 

0  ms 

67  ms 

transpose 

16  ms 

400  ms 

upto.suml 

0  ms 

168  ms 

upto.sum2 

0  ms 

66  ms 

Benchmark 

sonic  -1-  ECCE 

ECCE 

advisor 

17  ms 

150  ms 

applast 

83  ms 

33  ms 

doubleapp 

50  ms 

34  ms 

map  .reduce 

33  ms 

50  ms 

map.rev 

50  ms 

67  ms 

match.kmp 

300  ms 

166  ms 

matchapp 

66  ms 

83  ms 

maxlength 

184  ms 

200  ms 

regexp.rl 

34  ms 

400  ms 

relative 

50  ms 

166  ms 

remove 

367  ms 

400  ms 

remove2 

1049  ms 

216  ms 

reverse 

50  ms 

50  ms 

rev_acc_type 

316  ms 

83  ms 

rotateprune 

67  ms 

183  ms 

ssupply 

34  ms 

100  ms 

transpose 

50  ms 

467  ms 

upto.suml 

33  ms 

284  ms 

upto.sum2 

50  ms 

83  ms 

Table  1.  Specialisation  times  (total  w/o  post-  Table  2.  Specialisation  times  (unfolding) 

processing) 


All  the  benchmarks  are  taken  from  the  DPPD  library  ([27])  and  were  run  on  a  Power  Macintosh  G3  266 
Mhz  with  Mac  OS  8.1  using  SICStus  Prolog  3  #6  (Macintosh  version  1.3).  Tables  1  and  2  show  respectively, 
the  total  specialisation  times  (without  post-processing),  and  the  time  spent  in  unfolding  during  specialisation.^ 
In  Table  1  the  times  to  produce  the  generating  extensions  for  the  sonic  approach  are  not  included,  as  this 
is  still  done  by  hand.  It  is  possible  to  automate  this  process  and  one  purpose  of  hand-coding  the  generating 
extensions  was  to  gain  some  insight  into  how  this  could  be  best  achieved.  In  any  case,  in  situations  where 
the  same  program  is  repeatedly  respecialised,  this  time  will  become  insignificant  anyway.  Due  to  the  limited 
precision  of  the  statistics/2  predicate,  the  figures  of  “0  ms”  in  Table  2  should  be  interpreted  as  “less  than 
16  ms.”  (The  runtimes  for  the  residual  programs  appear  in  Table  3  in  the  appendix  for  referees,  which,  for  a 
more  comprehensive  comparison,  also  includes  some  results  obtained  by  MIXTUS.) 

The  sonic  prototype  implements  a  more  agressive  unfolding  rule  than  the  default  determinate  unfolding 
rule  of  ECCE.  This  is  at  the  expense  of  total  transformation  time  (see  Table  1),  as  it  often  leads  to  increased 
polyvariance,  but  consequently  the  speed  of  the  residual  code  is  often  improved,  as  can  be  seen  in  Table  3.® 
Default  ECCE  settings  more  or  less  guarantee  no  slowdown,  and  this  is  reflected  in  Table  3,  whereas  the  general 
lack  of  deterraincay  control  in  the  prototype  sonic  unfolding  rule  leads  to  two  small  slowdowns.  There  is  plenty 
of  room  for  improvement,  however,  on  these  preliminary  results.  For  instance,  the  sonic  approach  is  flexible 
enough  to  allow  determinacy  control  to  be  incorporated  within  it. 

All  in  all,  the  sonic  approach  provides  extremely  fast  unfolding  combined  with  very  good  specialisation 
capabilities.  Observe  that  the  sonic  approach  even  passes  the  KMP  test,  and  it  is  thus  the  first  offline  approach 
to  our  knowledge  which  does  so.'^  If  it  were  possible  to  extend  the  sonic  approach  to  the  global  control  as  well, 
one  would  hopefully  obtain  an  extremely  efficient  specialiser  producing  highly  optimised  residual  code. 


^  Note  that,  because  ecce  uses  characteristic  trees  whereas  the  sonic  prototype  builds  trace  terms,  running  the  latter 
involves  some  extra  (in  principle  unnecessary)  overhead. 

^  A  more  agressive  unfolding  rule,  in  conjunctive  partial  deduction,  did  not  lead  to  improved  speed  under  compiled  code 
of  Prolog  by  BIM;  see  [28].  So,  this  also  depends  on  the  quality  of  the  indexing  generated  by  the  compiler. 

^  One  might  argue  that  the  global  control  is  still  online.  Note,  however,  that  for  KMP  no  generalisation  and  thus  no 
global  control  is  actually  needed. 
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7  Conclusion 

The  majority  of  termination  analyses  rely  on  the  derivation  of  level  mappings  to  prove  termination.  This  paper 
has  described  how  these  level  mappings  may  be  used  to  obtain  precise  depth  bounds  for  the  control  of  unfolding 
during  partial  deduction.  Thus,  a  solid  link  has  been  established  between  the  fields  of  static  termination  analysis 
and  partial  deduction  enabling  existing  and  future  termination  analyses  to  be  used  to  ensure  finiteness  of  the 
unfolding  process. 

Furthermore,  the  paper  has  described  now  such  depth  bounds  can  be  incorporated  in  generating  extensions. 
The  construction  of  these  forms  the  foundation  of  any  offline  partial  deduction  method  whether  it  is  based  on 
the  self-application  or  the  cogen  approach.  This  is  the  first  offline  technique  which  allows  arbitrarily  partially 
instantiated  goals  to  be  sufficiently  unfolded  to  achieve  good  specialisation  results.  The  technique  can,  surpris¬ 
ingly,  yield  even  better  specialisation  than  a  pure  online  technique.  This  is  due  to  the  availability  of  global 
information  in  the  unfolding  decision  making  process.  It  is  also,  to  our  knowledge,  the  first  offline  approach 
which  passes  the  KMP  test. 

■i;  admits  elegant  solutions  to  some  problematic  unfolding  issues  and  these  solutions  are  sig¬ 

nificantly  less  complex  than  their  online  counterparts.  Of  course,  an  online  technique  may  still  be  able  to  make 
refined  unfolding  decisions  based  on  the  availabilty  of  concrete  data.  This  strongly  suggests  that  offline  and 
online  methods  be  combined  to  achieve  maximal  unfolding  power.  Another,  possibly  more  challenging,  avenue 
for  further  research  is  to  extend  the  sonic  approach  for  the  global  control,  so  that  its  advantages  in  terms  of 
efficiency,  termination,  and  specialisation  power  also  apply  at  the  global  control  level. 
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A  Further  Figures  and  Tables 


Flatten([| 

:i].  [2]]-  r,  2) 

1 

■e-  Append([l],  y,  r,  1 

)  A  Flatten([[2]],  y,  1) 

■f-  Append([],  y,  rl,  0' 

)  A  Flatten([[2]],  y,  1) 

•e-  FlattenI 

[[[2]],  y,  1) 

Append([2],  yl,  y,  1)  A  Flatten([],  yl,  0) 


■<-  Append(0,  yl,  r2.  0)  A  Flatten([],  yl,  0) 
<-  Flatten([],  yl,  0) 


T 

□ 


Fig.  1.  Unfolding  of  ■(-  Flatten([[l],  [2]],  r,  2) 
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1  Introduction 


Turchin  s  supercompiler  [19]  is  a  program  transformer  for  functional  programs  which  performs  optimizations 
beyond  partial  evaluation  [8]  and  deforestation  [21], 

Positive  supercompilation  [6]  is  a  variant  of  Turchin’s  supercompiler  which  was  introduced  in  an  attempt  to 
study  and  explain  the  essentials  of  Turchin’s  supercompiler,  how  it  achieves  its  effects,  and  its  relation  to  other 
transfomers.  In  particular,  the  language  of  the  programs  to  be  transformed  by  positive  supercompilation  is  a 
typical  first-order  functional  language  -  the  one  usually  studied  in  deforestation  -  which  is  rather  different  from 
the  language  Refal,  usually  adopted  in  connection  with  Turchin’s  supercompiler. 

For  the  sake  of  simplicity,  the  positive  supercompiler  was  designed  to  maintain  positive  information  only 
that  IS,  when  the  transformer  reaches  a  conditional  if  3:=a:'thentelset',  the  information  that  a:  =  a;'  is  assumed 
to  hold  is  taken  into  account  when  transforming  t  (by  performing  the  substitution  a:  i-)-  a;'  on  t).  In  contrast 
the  negative  information  that  x  x'  must  hold  is  discarded  when  transforming  t'  (since  no  substitution  can 
represent  this  information!).  In  Turchin’s  supercompiler  this  negative  information  is  maintained  as  a  constraint 
when  transforming  t .  Consequently,  Turchin’s  supercompiler  can  perform  some  optimizations  beyond  positive 
supercompilation.  ' 

In  this  pa,per  we  present  an  algorithm  which  we  call  perfect  supercompilation  -  a  term  essentially  adopted 
from  [5]  -  which  is  similar  to  Turchin’s  supercompiler.  The  perfect  supercompiler  arises  by  extending  the  positive 
supercorapiler  to  take  negative  information  into  account.  Thus,  we  retain  the  typical  first-order  language  as  the 
language  of  programs  to  be  transformed,  and  we  adopt  the  style  of  presentation  from  positive  supercompilation. 

A  mam  contribution  of  the  extension  is  to  develop  techniques  which  manipulate  constraints  of  a  rather  general 
form.  Although  running  implementations  of  Turchin’s  supercompiler  use  such  techniques  to  some  extent  the 
techniques  have  not  been  presented  in  the  literature  for  Turchin’s  supercompiler  as  far  as  we  know.  The  only 
exception  is  the  paper  by  Gliick  and  Klimov  [5]  which,  however,  handles  constraints  of  a  simpler  form;  for 
instance,  our  algorithm  for  normalising  constraints  has  no  counterpart  in  their  technique.  As  another  rnain 
contribution  we  generalise  a  technique  for  ensuring  that  positive  supercompilation  always  terminates  to  the 
perfect  supercompiler  and  prove  that,  indeed,  perfect  supercompilation  terminates  on  all  programs  As  far  as 
we  know,  no  version  of  Turchin’s  supercorapiler  maintaining  negative  information  has  been  presented  which  in 
general  is  guaranteed  to  terminate. 


The  remainder  of  this  extended  abstract  is  organized  as  follows.  We  first  (Section  2)  present  a  classical 
application  of  positive  supercompilation  (of  transformers  in  general):  the  generation  of  an  efficient  specialised 
string  pattern  matcher  from  a  general  matcher  and  a  known  pattern.  As  is  well-known,  positive  supercompi- 
lation  generates  specialised  matchers  containing  redundant  tests.  We  also  show  how  these  redundant  tests  are 
eliminated  when  one  uses  instead  perfect  supercompilation.  We  then  (Section  3)  present  an  overview  of  perfect 
supercompilation  and  (Section  4)  an  overview  of  the  proof  that  perfect  supercompilation  always  terminates.  In 
bection  0  we  conclude  and  compare  to  related  work. 
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2  The  Knuth-Morris-Pratt  Example 

Consider  the  following  general  matcher  program^  which  takes  a  pattern  and  a  string  as  input  and  returns  True 
iff  the  pattern  occurs  as  a  substring  in  the  string. 

match{p,s)  —m{p,s,p,s) 

m([l,ss,op,  os)  =  True 

m{p:pp,  ss,  op,  os)  =  x(p,pp,  ss,  op,  os) 
x{p,pp,\},op,os)  =  False 

x(p,pp,  s-.ss,  op,  os)  —  if  p=s  then  m(pp,  ss,  op,  os)  else  n{op,  os) 
n{op,s-.ss)  =  m{op,ss,op,ss) 

Now  consider  the  following  naively  specialised  matcher  matchp,^^-Q  which  matches  the  fixed  pattern  [A,A,B] 
with  a  string  u  by  calling  motc/j: 

match p,^p,^{u)  =  match{[A,A,B],u) 

Evaluation  proceeds  by  comparing  A  to  the  first  component  of  u,  A  to  the  second,  B  to  the  third.  If  at  some 
point  the  comparison  failed,  the  process  is  restarted  with  the  tail  of  u. 

This  strategy  is  not  optimal.  Suppose  that  after  matching  the  two  ri’s  in  the  pattern  with  the  first  two  ri’s  in 
the  string,  the  B  in  the  pattern  fails  to  match  yet  another  A  in  the  string.  Then  the  process  is  restarted  with  the 
string’s  tail,  even  though  it  is  known  that  the  first  two  comparisons  will  succeed.  Rather  than  performing  these 
tests  whose  outcome  is  known,  we  should  skip  the  three  first  A’s  in  the  original  string  and  proceed  directly  to 
compare  the  B  in  the  pattern  with  the  fourth  element  of  the  original  string.  This  is  done  in  the  KMP  specialised 
matcher: 

”*aab(0)  = 

”^AAb(®''®^)  =  if  ^=s  then  sllse  mAAB(®®)  ' 

”^Ab(D) 

mAB(^-®s)  =  if  then  mB(ss)  else  mAAB(*®) 

™b(D)  =  False 

m^{s:ss)  =  if  B=s  then  True  else  if  then  m^{ss)  else  niAAB(®®) 

After  finding  two  A’s  and  a  third  symbol  which  is  not  a  R  in  the  string,  this  program  checks  (in  mg)  whether 
the  third  symbol  of  the  string  is  an  A.  If  so,  it  continues  immediately  by  comparing  the  next  symbol  of  the 
string  with  the  B  in  the  pattern  (by  calling  mg),  thereby  avoiding  repeated  comparisons. 

Can  we  get  this  program  by  application  of  positive  supercompilation  to  the  naively  specialised  matcher? 
The  result  of  this  application  is  depicted  graphically  in  Figure  1.  We  do  not  have  space  to  explain  this  in  detail; 
informally,  each  arc  represents  a  step  of  transformation.  At  the  same  time  the  tree  can  be  viewed  as  a  new 
program,  where  arcs  with  labels  (e.g.  u  =  [])  represent  tests  on  the  input,  and  the  leaves  represent  final  results 
or  recursive  calls.  In  fact,  the  program  corresponding  to  the  tree  is  the  following: 

"*AAb(0)  = 

”*AAb(®  •  lihen  mAB(ss)  else  nAAB(^*! 

"^Ab(D)  = 

jtiabC®  •  if  ®  then  mB(ss)  else  nji^^iss, s) 

wibCD)  =  False 

mQ{s  :  ss)  =  if  B=sthenTrue  else  n^{ss,s) 

«AAb(«s.s)  ==faAAB(««) 

^Ab(®^!  ®)  if  then  toab(^*)  ®i®®  aAAB(®^)  ®) 
nB(ss,  s)  =  if  A=s  then  m]3(ss)  else  nAB(s5,  s) 

The  term  mAAB(a)  ia  this  program  is  more  efficient  than  match{[A,A,B],u)  in  the  original  program.  In  fact, 
this  is  the  desired  KMP  specialised  matcher,  except  for  the  redundant  test  A  =  s  in  tiab  •  The  reason  for  the 

^  We  use  standard  shorthand  notation  []  and  y.ys  for  the  empty  list  respectively  the  list  constructed  from  y  and  the  tail 
ys.  The  auxiliary  function  x  in  the  program  is  motivated  by  certain  restrictions  of  the  object  language.  Observe  that 
although  this  example  only  compare  variables  to  variables,  our  method  can  manipulate  more  general  equalities  and 
inequalities.  ' 
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redundant  test  ^  -  s  is  that  positive  supercompilation  ignores  negative  information:  when  proceeding  to  the 
false  branch  of  the  conditional  (from  the  original  program) 

if  then  (A:s:ss))  else  n([MS],(A:s:ss))  (*) 

the  information  that  s  holds  is  forgotten.  Therefore,  the  test  is  repeated  in  the  subsequent  conditional 

if  A=s  then  m{[A,B],ss,  [AAB],  {s-.ss))  else  n{[AAB],  {s-.ss))  (+) 

contrast,  in  perfect  supercompilation,  this  information  is  maintained  as  a  constraint,  and  can  be  used 
to  decide  that  the  conditional  (+)  has  only  one  possible  outcome.  The  tree  would  therefore  continue  below 
the  node  (+),  and  the  resulting  program  would  have  a  recursive  call  back  to  the  rightmost  child  of  (*)•  this  is 
exactly  the  KMP  specialised  matcher.  For  another  example  of  the  use  of  negative  information,  see  [14].' 


3  Overview  of  Perfect  Supercompilation 

The  transformation  is  carried  out  in  two  phases.  First,  a  model  of  the  subject  program  is  constructed  in  form 
of  &  process  tree  similar  to  the  one  in  Figure  1.  Second,  a  new  program  is  extracted  from  the  process  tree 
The  root  of  the  process  tree  consists  of  the  initial  term  that  is  to  be  specialised  and  an  empty  constraint 
system  The  process  tree  is  developed  by  repeated  unfoldings  of  the  terms  in  the  leaves.  The  rules  that  govern 
the  unfolding  of  terms  are  constructed  by  extending  the  small-step  semantics  of  the  language  by  rules  that 
speculatively  executes  tests  that  depend  on  variables.  For  each  possible  outcome  of  a  test,  a  child  is  added 
and  information  about  the  test  that  has  been  conducted  is  appended  to  the  current  constraint  system  The 
extended  constraint  system  is  then  passed  on  to  the  child  that  resulted  from  the  speculative  execution.  A 
constraint  system  [1]  is  a  restricted  kind  of  conjunctive  normal  form  of  formulae  of  the  form 


f\ai  =  a'A  hi 

/  \i=l 

where  a,  b  are  terms  that  consist  of  variables  and  constructors  only,  Le. 

ci,  b  ..  X  I  c(q,i  , . . . ,  . 

The  constraint  systems  are  used  to  prune  branches  from  the  process  tree:  speculative  execution  of  a  test  that 
results  in  a  constraint  system  that  cannot  be  satisfied  will  not  produce  a  new  child.  For  a  constraint  system 
0  be  satisfiable,  it  must  be  possible  to  assign  values  to  the  variables  in  the  system  such  that  the  constraints 
are  satisfied.  A  constraint  system  is  thus  satisfiable  if  there  exists  a  substitution  0  such  that,  for  each  equation 
a  -  a  a0  will  be  syntactically  equal  to  a'e,  and  likewise,  for  each  disequation  b  ^  b',  be  will  be  syntactically 
different  from  b  0.  The  satisfiability  of  a  constraint  system  can  be  decided  by  a  mere  syntactic  check  of  a  normal 
form  tor  a  constraint  system.  A  constraint  system  in  normal  form  is  either  ±  (false),  T  (true),  or  of  the  form 

^  A  (y 

j=i  \k=i  / 

where  are  variables.  The  normal  form  of  a  constraint  system  can  be  calculated  by  a  series  of  rewrite 
steps^  The  core  of  these  rewrite  rules  are  shown  in  Figure  2.  Additional  control  on  these  rules  ensure  that 
non-deternunistic,  exhaustive  application  of  the  rewrite  rules  to  any  constraint  system  terminates  and  results 
in  a  constraint  system  in  normal  form. 

nn  /2/pe  _*7^ormafron  about  the  variables  in  a  constraint  system  is  present,  a  constraint  system  in 

normal  form  is  satisfiable  exactly  when  it  is  different  from  ±.  However,  when  it  is  known  that  the  size  of  the 
domain  of  values  is  finite  iov  some  variable  x,  it  is  necessary  to  verify  that  there  indeed  exists  a  value  which, 
when  assigned  to  x,  satisfies  the  constraint  system.  To  see  this,  consider  the  constraint  system 

X  A  y  z  Az  ^  X 

where  all  variables  have  boolean  type.  This  system  is  in  normal  form  and  therefore  appears  to  be  satisfiable  - 
but  it  is  not  possible  to  ^sign  values  False,  True  to  the  variables  such  that  the  system  is  satisfiable  It  is  thus 
necessary  to  systematically  try  out  all  possible  combinations  of  value  assignments  for  variables  This  can  be 
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;  match{{A,A,B],u)  ] 

... . 

m{[A,A,B],  u,  [AAB],  u)  ■ 


(J^<  ^ A, [AB], w, [AAB],u)) 


f  if  A  =  a  \ 

then  m([AB],  as,  {AAB\,  (a-.aa)) 
k  else  n([j4,/l,J5],  (s:ss))  J 


.  n{[AAB],  (s;ss))  i 
{m{[AAB],  sa,  [44B],  as)  i 


(i(A,  [A,  B],  aa,  [A,  A,  B],  ssP 


■  m{[AB],  38,  [AAB],  A:ss)  :  i  n{[AAB],  (A:a:aa)) 

^ . . '  :  f . . 

[B],ss,[A,A,S],  A:ss)j  ;  m([AA-B],  (srss),  [A,A,B],  (s:ss)) : 

^ —  I 

^  if  A-a  ~P)\  . . I . 

j  then  m([J3],  sa,  [A,A,jB],  (A:s:ss))  j  ®(A,  [AB],  (s:ss),  [AAB],  (s:ss)) : 
V  else  n([A,A-B],  (A:s:ss))  J  I 


:  m{[B],  as,  [AAB],  A:A:as)  i 


^  ifA  =  s  (+> 

then  m{[AB],  as,  [AAB],  (s:ss)) 

V  else  n{[AAB],  {s:ss))  j 


(>W£e)<7;qj-(a:(5,D>S'5.  [AA,5],A:A:ss))  _ ni[AAB],  (AiAiaisa))  ) 

g3=(5!flj)i  ^ - ■■  I 

1^  if  B  =  s  . y 

then  m([],  as,  [AAB],  {A:A:S:ss))  j  I  m{[AAB],  {A-.s:ss),  [AAB],  (A:s:ss)) 
\else  n([j^A,B],  (A;A:s:ss))  J 

. ’  .  . 

(jVue)< - m([],  as,  [A,AB],  A:A:B:ss)  :  ;  x{A,  [A,  B],  (A:s:ss),  [AAB],  A;s:ssj  ; 


ifA  =  A 

then  m([A,B],  (a;sa),  [AAB],  (A:s:ss)) 
,  else  n(iA,A,B],  (A;a:as)) 

. i... . . 

;  m{[AB],  (s:as),  [AAB],  (A:s:ss)) ) 
!b(A,  [B],  (s:as),  [A,A,S],  (A:s:sa)) ; 


i'  if  A  =  a  > 

then  m([B],  as,  [AAB],  (A:s:ss)) 

V  else  n(\AAB]i  (A:a:ss))  J 


Fig.  1.  Driving  the  naively  specialised  matcher 


(c  c') 
(c  c') 


X  =  X  T 

X  ^  X  1-4  ± 

•  A  T  1-4  • 

•  V  ±  I-4  • 

•  A  ±  1-4  1 

•  VT  H4  T 

c(6i,.. 

.,bn)  =c'(ai,. 

..,am)  1-4  J- 

c(6i,.. 

■  ,bn)  ^  c'(ai, . 

•  •  )  dm)  1— t  T 

c{bi,. 

•  *  ,  bn^  ~  c(Q/1  ,  . 

. . ,  an)  e-4  6i  =  ai  A  . . .  A  fen  =  Ui 

c(6i,. 

■  ■,bn)^  c{ai,. 

.  • ,  On)  1-4  fei  ^  ai  V  . . .  V  fen  ^  a, 

X  =  a  H- 1 
X  a  i->  T 

x  =  aA»H>x  =  aA  •{x:=a} 
X?^aV*f-^x^aV  •{x:=:a} 


(x  e  Var(a)&:a  ^  x) 
(x  e  Var(a)&a  ^  x) 
(x  ^  Var{a)) 

(x  0  Var(a)) 


Fig.  2.  Rewrite  system  for  normalisation  of  constraint  systems.  •  stands  for  an  arbitrary  part  of  a  formula. 


achieved  by  instantiation  of  such  variables,  which  will  call  for  further  rewrite  steps,  and  so  on  until  it  is  proven 

that  the  system  is  satisfiable.  For  a  full  treatment  of  the  normalisation  and  satisfiability  of  constraint  systems 
see  [14].  ^  ’ 

We  can  now  show  how_ constraint  systems  can  be  used  to  guide  the  construction  of  the  process  tree.  Every 
term  t  in  the  process  tree  is  associated  with  a  constraint  system  7^,  denoted  The  complete  set  of  unfold 

rules  IS  presented  in  Figure  3.  Rules  (1),(2),(4),  (7)-(ll)  and  (12)  correspond  to  normal  evaluation  with  respect 
to  the  semantics  of  language  .  Rules  (3), (5)  and  (6)  perform  speculative  execution  of  a  term  based  on  the 
information  in  the  associated  constraint  system. 

^  Rule  (3)  instantiates  a  free  variable  y  to  the  pattern  c(yi, . . .^y^  taken  from  the  function  definition.  This 
is  achieved  by  appending  the  equation  y  =  c{yx , . . y^)  to  the  current  constraint  system.  If  the  new  constraint 
system  IS  satisfiable,  the  function  application  can  be  unfolded.  In  the  same  manner,  rules  (5)  and  (6)  han¬ 
dle  conditional  expressions,  but  more  complex  equations  and  disequations  are  allowed.  Rule  (11)  propagates 
instantiations  performed  in  a  subterm  to  the  surrounding  term.  For  a  full  description,  see  [14]. 

Unfolding  of  a  branch  is  stopped  if  the  leaf  in  that  branch  is  a  value  or  if  an  ancestor  node  covers  all  possible 
executions  that  can  arise  from  the  leaf.  In  the  latter  case,  a  fold  operation  is  performed  which  will  result  in  a 
recursive  call  in  the  derived  program. 

How  do  we  decide  that  a  node  covers  another  node?  Well,  first  of  all  the  terms  of  the  two  node  must  be  equal 
up  to  renaming  of  variables;  secondly  the  constraint  system  of  the  leaf  must  be  at  least  as  restrictive  as  the 
one  of  Its  ancestor.  K  these  conditions  are  met,  we  can  safely  produce  a  recursive  call  in  the  derived  program. 
We^  have  constructed  an  algorithm  that  gives  a  safe  approximation  to  the  question  “is  Tl  more  restrictive  than 

by  deterministic 

rln  r  ;•  Tl  °f  a  single  path.  This  is  a  good  sign,  since  it  means  that  they  represent  local 

computatmns  that  will  always  be  carried  out  when  the  program  is  in  this  particular  state,  regardless  of  the 
unmstantiated  variables.  We  can  thus  precompute  these  intermediate  transitions  -  as  done  in  partial  evaluation 
once  and  for  all,  throw  away  the  intermediate  steps  and  just  remember  the  results.  Such  local  unfoldings  will 
not  only  decrease  the  size  of  our  process  trees,  they  will  also  allow  us  to  ensure  that  folding  is  not  carried  out 
prematurely,  thus  losing  potential  specialisation. 

Creation  of  a  process  tree  in  the  manner  just  described  does  not  always  terminate  since  infinite  process  trees 
e  produced,  the  simple  fold  when  possible”  strategy  does  not  ensure  termination.  To  keep  the  process 
trees  finite,  we  ensure  that  no  infinite  branches  are  produced.  It  turns  out  that  in  every  infinite  branch  there 
must  be  a  term  ih&t  homeomorphically  embeds  an  ancestor  -  this  is  known  as  Kruskal’s  Tree  Theorem.  The 
homeomorphic  embedding  <  is  the  smallest  relation  on  terms  such  that, 

_  n}:t<t',  Vi  €  {1, . . .  ,n}  :  <  t' 

_ _  t<h{t[,...,t'J 

'  semantics  of  language  is  evaluation  to  weak  head  normal  form,  except  for  comparison  in  conditionals 

where  the  terms  to  be  compared  are  fully  evaluated  before  the  comparison  is  carried  out.  conditionals 


_ f{xi,...,Xn)=U  _ 

.  .  _ _ f(^c(^Xi^...yXrn)iXrn+li‘‘’iXn)  —  t 

^  (/(c(il,  .  .  .,tm),tm+l,  ■  ■  ■,tn),Ti')  {t{Xi:=tl,  ...,Xn  ■=^tn},Tl) 


f{c{yi,...,ym),Xl,...,Xn)  =  t 

-R'  =11  A[y  =  c{yi,. .  .,ym)]  satisfiable(7e') 

{f{y,ti, . . .  ,tn),R)  {t{xi:=ti,. . .  ,xn~t„},n') 

ficiyi,--->ym),Xl,...,Xn)  to  {t,'R)  {t',1l') 

■'  (/(i,  ti, . .  .  ,  tn),  7^)  ->  {fit'M , , . .  ,  tn),  n') 

1i!  =11  h[a  =  a']  satisfiable(7^') 

^  (if  a=o'  then  t  else  t' ,11)  (t,'??-') 

n'  =11  A[a^  g']  satisfiable(7^') 

^  (if  a=a^  then  t  else  t',1Z)  — >  {t',1Z') 


_ _ (ti,7i}^(t'i,7e) _ 

'■  '  (if  ti=t2  then  h  else  t4,1l)  ->  (if  t'l^h  then  ta  else  U,1l) 

_ (t2,7e)  (t'a.Te) _ : 

^  ^  (if  o=t2  then  ts  else  U,1l)  (if  a=t2  then  ta  else  U,1l) 

-4  (^^7^) 


(10) 


{t,1l)^{t',n) 


(c(fll ,  ,  .  .  ,  (li,t,  ti-{~l ,  ,  •  ,  ,tn),  1^)  (c(fltl  j  .  .  •  5  Oi  j  t  j  ti-j-i  j  .  .  .  j  tn))  R'  ) 


(11) 


(t,72.)  {t',1Z')  9  is  the  substitution  extracted  from  R' 

{t,ii)  ^  {t'e,n'e) 


(12) 


i  G  {l,...,n} 


Fig.  3.  Unfold  rules.  x,y  ranges  over  variables,  f  ranges  over  function  names,  c  ranges  over  constructors,  t  ranges  over 
terms,  and  a  ranges  over  terms  that  does  not  contain  function  calls. 
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ranges  over  constructor  and  function  names,  a;  and  y  range  over  variables,  and  t  ranges  over  terms. 
When  a  leaf  homeomorphically  embeds  an  ancestor,  there  is  thus  a  danger  of  producing  an  infinite  branch. 
In  such  a  situation,  the  nodes  in  question  are  collapsed  into  one  by  a  generalisation  step. 

Definition  1  (Generalisation). 

1.  A  term  s  is  an  instance  of  term  t,  denoted  t  <•  s,  if  there  exists  a  substitution  9  such  that  tB  =  s. 

2.  A  generalisation  of  two  terms  t,  s  is  a  term  u  such  that  u  <•  t  and  u<s. 

3.  A  most  specific  generalisation  (msgj  of  two  terms  t,  s  is  a  generalisation  u  such  that,  for  all  generalisation 
u'oft,s,u<u. 

There  exists  exactly  one  msg  of  t,  s  modulo  renaming.  A  generalisation  step  calculates  the  msg  of  the  nodes 
which  IS  then  used  to  divide  one  of  the  nodes  into  subterms  that  can  be  unfolded  independently: 


[let  xi=t[,...,Xn-t'^  in  t"~) 

where  t"  is  the  nisg  of  t  and  t'.  Which  of  the  nodes  that  is  split  up  depends  on  how  similar  the  nodes  are- 
see  [14]  for  more  detail.  ’ 

We  ^n  now  sketch  the  full  supercompilation  algorithm.  To  ensure  termination  and,  at  the  same  time,  provide 
reasonable  specialisation,  we  partition  the  nodes  in  the  process  tree  into  three  categories: 

1.  nodes  labelled  by  let-terms, 

2.  global  nodes,  and 

3.  local  nodes. 

Glob^  nodes  are  those  nodes  that  represent  speculative  execution  and/or  instantiation  of  variables.  Local  nodes 
Me  those  nodes  that  are  not  global  and  does  not  contain  let-terms.  For  example,  in  Figure  1  the  set  of  local  nodes 
ndicated  by  dotted  fram^  (there  are  no  nodes  containing  let-terms  since  there  is  no  need  for  generalisation 
in  that  particular  example).  This  partitioning  of  the  nodes  is  used  to  control  the  unfolding. 

Definition  2.  Let  T  be  a  process  tree  and  7  a  node  in  T.  Then 

^(7)  denotes  the  label  of  node  7. 

£  ny.^T'}  denotes  a  new  tree  that  is  identical  to  T  except  that  the  subtree  rooted  at  7  has  been  replaced  by 
3.  e  denotes  the  root  node  of  a  tree. 

Definition  3.  Let  T  be  a  process  tree  and  j  be  a  leaf  node  in  T.  Then 

drive(T,7)  =  T{7:=  T(j)  } 


where  {ti, . . . , =  {t  )  T(7)  t}. 

Definition  4.  A  leaf  j  in  a  process  tree  T  is  finished  if  one  of  the  following  conditions  are  satisfied: 

1.  T(7)  =  (c(), . . .}  for  some  constructor  c. 

2.  T(7)  =  (x,  . . .)  for  some  variable  x.  " 

'inT{'^')  ™  ^  ^  renaming  of  the  term 

A  tree  T  is  said  to  he  finished  when  all  leaves  are  finished. 
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Definition  5.  Let  T  be  a  process  tree  and  let  the  set  of  relevant  ancestors  relanc(T',7)  to  a  node  7  in  T  be 
defined  thus: 

{0,  «/7  contains  a  let-term 

all  ancestors  that  are  global,  if  7  is  global 
all  local  ancestors,  if  7  is  local 

where  the  local  ancestors  to  7  is  all  ancestors  that  are  local  up  to  the  first  common  ancestor  that  is  global. 

For  an  example,  consider  the  process  tree  in  Figure  1;  the  local  node 
x{A,  [B],  (s:ss),  [A,A,B],  (A:s;ss))  at  the  bottom  has  as  local  ancestors  all  ancestors  up  to  and  including  the  node 
n{[A,A,B],{A-.A‘.s-.ss)). 

With  these  definitions,  we  can  sketch  the  supercompilation  algorithm  thus: 
input  t 

let  T  consist  of  a  single  node  labelled  {t,T) 
while  T  is  not  finished  begin 
let  7  be  an  unfinished  leaf  in  T 

if  V7'  €  relanc(T,j)  :  T{j')  ^  r(7)  then  T  ~  driveiT,^) 
else  begin 

let  7'  e  relanc{T,  7) 
if  T{7')  <-T(7)  then  generalise  r(7) 
else  generalise  T(7') 
end 
end 

return  T 


The  transformed  program  can  be  extracted  from  the  process  tree  by  examination  of  the  global  nodes  and  the 
annotations  on  the  edges. 

4  Overview  of  the  Termination  Proof 

A  language-independent  framework  for  proving  termination  of  abstract  program  transformers  has  been  presented 
in  [16],  where  sufficient  conditions  have  been  established  for  abstract  program  transformers  to  terminate. 

An  abstract  program  transformer  is  a  map  from  trees  to  trees,  such  that  a  single  step  of  transformation  is 
carried  out  by  each  application  of  the  transformer.  Termination  then  amounts  to  a  certain  form  of  convergence 
of  sequences  of  trees.  In  the  metric  space  of  trees,  the  distance  between  two  trees  is  measured  by  the  depth  to 
which  they  first  differ,  i.e.  the  further  down  one  should  go  find  a  difference,  the  more  alike  are  the  trees.  The 
main  idea  is  to  ensure  that 

1.  the  transformer  converges,  in  the  sense  that  for  each  transformation  step,  the  process  tree  gets  still  more 
stable,  and 

2.  the  transformer  maintains  some  invariant  such  that  only  finite  trees  are  produced. 

Theorem  1.  LetM  be  an  abstract  program  transformer  that  maintains  a  predicate  p  on  (possibly  infinite)  trees. 

If 

1.  for  every  tree  T  consisting  of  a  single  node,  the  sequence  T,M{T),M{M{T)), . . .  is  a  Cauchy  sequence^; 
and 

2.  for  every  infinite  tree  T,  p{T)  is  false;  and 

3.  for  every  convergent  sequence  of  trees  Tq,Ti,T2,  with  limit  T,  the  sequence  p{T(j),p{Ti),p{T2), ...  stabilises 
top{T). 

then  M  terminates  on  all  trees  consisting  of  a  single  node. 

For  a  proof,  see  [16].  To  show  that  each  step  of  our  algorithm  for  perfect  supercompilation  develops  a  Cauchy 
sequence,  we  will  use  a  proposition  that  states  that,  if  an  abstract  program  transformer  operates  by  either  1) 
adding  new  children  to  a  leaf  node,  or  2)  replacing  a  subtree  by  a  new  subtree  that  is  strictly  smaller  (in  some 
sense) ,  then  the  transformer  produces  a  Cauchy  sequence  of  trees. 

^  For  a  metric  space  (X,  d),  a  sequence  *0,2:1,...  €  X  is  a  Cauchy  sequence  if,  for  all  e  >  0,  there  exists  an  A’'  6  N  such 
that,  for  all  7z,  m  >  N,  d{xn,  Xm)  <e. 
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Proposition  1.  Let  M  be  an  abstract  program  transformer  and  t  be  a  well-founded  quasi-order  on  the  labels 
of  the  trees  produced  by  M.  Furthermore,  for  all  trees  T,  let  M{T)  =  T{^:=T')  for  some  node  7  and  some  tree 
T  where 

1.  7  is  a  leaf  in  T  and  T(7)  =  T'{e)  (unfold);  or 

2.  r(7)  y  T'{e)  (generalise). 

Then  M  produces  a  Cauchy  sequence. 

For  a  proof,  see  [16].  Since  our  supercompiler  algorithm  can  be  viewed  as  an  instance  of  such  an  abstract 
program  transformer,  we  can  show  that  the  algorithm  produces  a  Cauchy  sequence  by  ensuring  that  a  well- 
founded  quasi-order  is  maintained  by  the  algorithm.  The  following  well-founded  quasi-order  is  used  for  that 
end:;  let  (^,7^)  5-  {t' ,11')  iff  either  t  is  not  a  let-term  and  t'  is  a  let-term,  or  size{n)  >  size{TZ'). 

We  now  know  that  our  algorithm  produces  still  more  stable  process  trees.  We  then  need  to  show  that  the 
supercompiler  does  not  “produce  infinite  trees”.  This  is  ensured  by  the  check  for  homeomorphic  embeddings  in 
algorithm.  For  full  details,  see  [14]. 


5  Conclusion  and  Related  Work 

We  have  presented  ^  algorithm  for  a  supercompiler  for  a  first-order  functional  language  that  maintains  positive 
as  well  as  negative  information.  The  algorithm  is  guaranteed  to  terminate  on  all  programs,  and  we  have  shown 
that  It  is  strong  enough  to  pass  the  so-called  KMP-test. 

In  [20],  Turchin  briefly  describes  how  the  latest  version  of  his  supercompiler  utilises  contraction  and  re- 
stncUon  patterns  in  driving  Refal  graphs,  the  underlying  representation  of  Refal  programs.  It  seems  that  the 
resolution  of  clashes  between  assignments  and  contractions/restrictions  can  achieve  propagation  of  negative 
information  that  -  to  some  extent  -  provides  the  power  equivalent  to  what  has  been  presented  in  the  present 
paper,  but  the  exact  relationship  is  at  present  nnrlpgr  to  us. 

In  the  field  of  partial  evaluation,  Consel  and  Danvy  [2]  have  described  how  negative  information  can  be 
incorporated  into  a  naive  pattern  matcher,  thereby  achieving  effects  similar  to  those  described  in  the  present 
paper.  This,  however,  is  achieved  by  a  non-trivial  rewrite  of  the  subject  program  before  partial  evaluation  is 
appued,  thus  rendering  full  automation  impossible. 

In  the  case  of  Generalised  Partial  Computation  [4],  Takano  has  presented  a  transformation  technique  [17]  that 
exceeds  the  power  of  both  Turchin’s  supercompiler  and  perfect  supercompilation.  This  extra  power,  however 
stems  from  ^  unspecified  theorem  prover  that  needs  to  be  fed  the  properties  about  primitive  functions  in  the 
anguage,  axioms  for  the  daita  structures  employed  in  the  program  under  consideration,  etc.  In  [18]  the  theorem 
prover  is  replaced  by  a  congruence  closure  algorithm  [13],  which  allows  for  the  automatic  generation  of  a  KMP- 
matcher  from  a  naive  algorithm  when  some  properties  about  list  structures  are  provided.  In  comparison  to 
supercompilation,  Generalised  Partial  Computation  as  formulated  by  Takano  has  no  concept  of  generalisation 
and  will  therefore  terminate  only  for  a  small  class  of  programs. 

When  one  abandons  simple  functional  languages  (as  treated  in  the  present  paper)  and  considers  logic  pro- 
pamming  and  constraint  logic  programming,  several  accounts  exist  of  equivalent  transformation  power,  e.g 
[15,7,9,10].  In  these  fi-ameworks,  search  and/or  constraint  solving  facilities  of  the  logic  language  provides  the 
necessary  machinery  to  avoid  redundant  computations.  In  this  field,  great  efforts  have  been  made  to  produce 
optimal  specialisation,  and  at  the  same  time  to  ensure  termination,  see  e.g.  [11, 12]. 
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Abstract.  We  show  that  linear  time  self-interpretation  of  the  pure  untyped  lambda  calculus  is  possible. 

The  present  paper  shows  this  result  for  reduction  to  weak  head  normal  form  under  call-by-name,  call-by¬ 
value  and  call-by-need. 

We  use  operational  semantics  to  define  each  reduction  strategy.  For  each  of  these  we  show  a  simulation 
lemma  that  states  that  each  inference  step  in  the  evaluation  of  a  term  by  the  operational  semantics  is 
simulated  by  a  sequence  of  steps  in  evaluation  of  the  self-interpreter  applied  to  the  term. 

By  assigning  costs  to  the  inference  rules  in  the  operational  semantics,  we  can  compare  the  cost  of  normal 
evaluation  and  self-interpretation.  Three  different  cost-measures  are  used;  number  of  beta-reductions,  cost 
of  a  substitution-based  implenientation  and  cost  of  an  environment-based  implementation. 

For  call-by-need  we  use  a  non-deterministic  semantics,  which  simplifies  the  proof  considerably. 

1  Program  and  data  representation 

In  order  to  talk  about  self-interpretation  of  the  pure  lambda  calculus,  we  must  consider  how  to  represent 
programs  as  data. 

We  will  use  the  representation  defined  (for  closed  terms)  in  [5]: 

\M'\  ^Xa.Xb.M 
where 
X  =  X 

PQ =aPQ 
Xx.P  =  b  Xx.P 

where  M  has  been  renamed  so  the  variables  a  and  b  do  not  occur  anywhere.  =  is  alpha-equivalence.  We  get  an 
exceedingly  simple  self-interpreter: 


selfint  =  Xm.m  1 1 

where  I  =  Xx.x.  It  is  trivial  to  prove  that  selfint  \M]  -+>  M. 

2  Linear  time  self-interpretation  using  call-by-name  reduction 

Call-by-name  evaluation  can  be  described  by  the  inference  rules: 

p\-Xx.M  =+  {Xx.M,  p)  (LAMBDA) 

p'[-M^W 

where  p(a:)  =  (M,p')  (VAR) 

ph-M  {Xx.M',  p')  p'[x^(N,p)]\-M'  +>  W 

~  p\-M  N  =^W  (BETA) 

We  can  define  various  cost  measures  by  assigning  costs  to  uses  of  the  inference  rules  in  an  evaluation  tree  For 
example,  we  can  count  beta  reductions  by  letting  each  use  of  the  (BETA)  rule  count  1  and  not  charge  anything 
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for  the  other  rules.  But  we  can  also  define  more  fine-grained  (and  more  realistic)  cost  measures  by  assigning 
different  costs. 

For  lack  of  space,  we  omit  showing  how  the  inference  rules  can  be  used  to  derive  the  initial  stages  of  self¬ 
interpretation  of  a  closed  term  M.  These  stages,  however,  define  the  relation  between  the  environments  used  in 
normal  evaluation  and  in  self-interpretation; 

0  -P'2 _ 

p\x^{S,p')]=^p[xy^{S,p')] 

where 

P2  =[a^-^{I,pl),b^(I,pl)] 

Pi  = 

The  empty  environment  is  denoted  [].  The  M  referred  to  in  pi  is  be  the  entire  term  being  interpreted.  Note 
that  \p\  =  IpI  -f  2.  We  need  a  simulation  lemma: 

Lemma  1.  If  we  from  the  call-by-name  inference  rules  can  derive  the  evaluation  p\- N  {Xy.W,  p')  then  we 
can  also  derive  the  evaluation  p\-N  (Xy.W,  p'). 


We  prove  lemma  1  by  induction  over  the  the  evaluation  tree  with  N  at  its  root: 

N  —  x:  Let  p(x)  =  (S,  p"): 

Normal  evaluation: 

N  —  Xy.W:  p\-N  =^(Xy.W,  p)  is  a  leaf  tree.  N  =  b  (Xy.W),  so  we  get 

pih-1  =^(I,pi)  pbXy.W  =^{Xy.W,p) 

phb  ^(Xz.ZjPi)  pi[z (Xy .W ,p)]\- z  =>  (Xy .W ,p) 
phb  (Xy.W')  =>  (Xy.W,  p) 

N  =  Ni  N2:  The  normal  evaluation  tree  is 


phNt  N2=^(Xy.W,  p') 

We  have  N  =  a  Ni  N2,  so  we  get  (by  induction)  the  following  tree  for  self- interpretation 


_ pl-Q  Ni  ^(Xv.Na,  p")  _ p" [u h-»- ( A^2 ,  p)]\- Ns  =^(Xy.W,  p') 

p\-aJhN^;^(Xy.W,7) 

Fig.  1.  Proof  of  lemma  1  n 

which  we  prove  in  figure  1.  We  use  in  this  (and  the  following  proofs)  a  notation  where  “•••”  refers  to  an 
unspecified  proof  tree.  This  is  to  indicate  where  an  induction  step  is  used;  If  normal  evaluation  has  a  proof  tree 
indicated  by  “•  •  we  replace  this  in  the  simulation  by  a  proof  tree  that  by  induction  is  assumed  to  exist.  This 
proof  tree  is  in  the  simulation  also  indicated  by  “■  Semantic  variables  (place  holders)  in  the  conclusion  of 
a  rule  where  the  premise  is  “•  ■  •” ,  can  be  considered  existentially  quantified,  like  variables  in  the  premise  of  an 
inference  rule  typically  are. 

By  assigning  costs  to  the  inference  rules,  we  can  count  the  costs  for  normal  evaluation  and  self-interpretation 
and  hence  prove  linear-time  self-interpretation.  We  start  by  counting  beta  reductions.  For  this,  we  let  each  use 
of  the  (BETA )  rule  count  1  and  the  other  rules  count  0. 

The  (not  shown)  tree  for  the  initial  stages  of  self-interpretation  uses  the  beta  rule  three  times,  so  this  tree 
has  cost  3.  For  the  remainder  of  the  computations  we  use  this  lemma; 

Lemma  2.  If  derivation  of  ph- N  (Xy.W,  p')  uses  n  beta-reductions,  then  derivation  ofp\-N  (Xy.W ,  7) 
uses  3n  -I- 1  beta-reductions. 


pihJ=»(J,pi) 
pi- a  =^(A2:.z,  pi) 


phiVi  ^(Av.iVs,  p'^  ^ 
oi\zi-^(Ni,  p)1l-z  ^(Aa.Ns,  p") 


p"hS^{Xy.W,p') 
p\-x  =>  (Xy.W,  p') 


Self-interpretation:  P 

^  p\-x=^(Xy.W,  p') 
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as 


induction  over  the  structure  of  the  evaluation  tree,  using  the  proof  of  lemma  1 

indi!!tEn  o^theTubtr™.^*  evaluation  nor  the  self-interpretation  uses  the  (BETA)  rule,  so  the  result  follows  by 

3  0^"!  -^l^^are  do™^^  evaluation  tree  has  cost  0  while  self-interpretation  uses  the  (BETA)  rule  once.  Since 

k  Assuming  the  subtrees  have  costs  ki  and  k2  respectively,  the  total  cost  of  normal  evaluation  is 

^  induction,  the  cost  for  the  subtrees  for  self- interpretation  are  3fci  -f  1  and  3/^2  -t- 1  and  the  tree 

uses  (BETA)  twice,  so  the  total  cost  is  3k,  +  3^2  +  4  =  3{Ai  +  ^2  +  1)  +  1,  whici  is  what  we  want. 


By  adding  the  cost  for  the  initial  states  of  self-interpretation,  we  get: 


Theorem  1.  If  a  closed  term  M  via  the  call-by-name  semantics  evaluates  to  a 
using  n  beta  reductions,  then  selfint  fM]  evaluates  to  a  WHNF  using  3n  +  i 


weak  head  normal  form  (WHNF) 
beta  reductions. 


2.1  A  more  realistic  cost  measure 

tiTs^rctSfidthVnff m  measuring  the  cost  of  reduction  of  lambda  terms.  In 

languSs  ^  ^  measures  that  emulate  common  methods  for  implementing  functional 

The  first  of  these  is  (simplified)  graph  rewriting.  In  graph  rewriting,  a  beta-reduction  is  implemented  bv 
making  a  new  copy  of  the  body  of  the  function  and  inserting  the  argument  in  place  of  the  variables  This  hi 

ni  ^  ^  innction  {Xx.M')  that  is  applied.  The  other 

ru  es  stiU  count  0,  as  the  use  of  environments  and  closures  in  the  inference  rules  do  not  directly  correspond  to 

frpp  iP>P)  as  the  term  obtained  by  substituting  the 

ee  v^iables  m  ^  by  the  values  bound  to  them  in  p,  after  the  same  has  been  done  recursively  to  these  values 
More  formally,  we  define  the  function  unfold  by:  ^ 


unfold{P,  [])  =  P 

unfold{P,p[x^{Q,p')])  =  unfold(P,p)[x\unfold{Q,p')] 

We  need  a  small  lemma 


Lemma  3.  unfold(P,p)  =  unfold(P,p)[a\/j[6\/], 

We  prove  this  by  induction  over  the  definition  of  unfold- 
unfold(P,  D)  =  P: 


unfold(P,  []) 

=  unfold(P,ps) 

-  unfoldlp, p2)[b\unfold{I, pi)] 

=  unfold{P,  p2)[b\I] 

=  'mfold{P[a\unfold{I ,  pi)],  0)[i\/] 

=  P[a\I][b\I] 

unfold{P,p[x^iQ,p')])  =  unfold{P,p)[x\unfold{Q,p")]-. 

unfold(P,p{x  (<5  ,_£')]) 

=  unfoldiP,  p[x  i-4  (Q,  p')]) 

_  _ by  definition  of  p 

=  unfold(P,  p)  [x\unfold{Q,  p')] 

_ _ _  _ _ by  definition  of  unfold 

=  mfold(P,p)[a\I][b\I][x\unfold{Q,rho')[a\I][b\I]] 

_ _ _  _ _ _  by  induction 

^  unfoldjP,  p)[x\unfold{Q,  r/n/)]ra\7lf6\/1 
=  unfoldiP,  p)[x\unfold{Q,  rho')][a\/][6\/] 


□ 
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We  count  the  size  of  a  term  as  the  number  of  nodes  in  the  syntax  tree,  i.e.  one  for  eac^ variable  occurrence 
plus  one  for  each  application  and  one  for  each  abstraction.  It  is  easy  to  see  that  the  size  of  P[a\/] [6\7]  is  strictly 
less  than  4  times  the  size  of  P. 

We  first  count  the  cost  of  the  initial  part_^  the  tree  to  be  \selfint\  =  8  for  the  first  beta  reduction, 

I  [M]  I  <  3|Af|  for  the  second  and  the  size  of  Xh.M  with  a  replaced  by  I  (<  A\M\)  for  the  third,  for  a  total  cost 
less  than  7|M|  +8. 

We  now  proceed  with  the  lemma 

Lemma  4.  If  derivation  of  p\- N  {Xy.W,  p')  has  cost  c,  then  derivation  of'pl-N  =>■  {Xy.W,  p')  has  cost  at 
most  4c  +  2 . 

Again  we  prove  this  by  induction  following  the  structure  of  the  proof  for  lemma  1. 

N  =  x:  Neither  normal  evaluation  nor  the  self-interpretation  uses  the  (BETA)  rule,  so  the  result  follows  by 
induction  on  the  subtrees. 

N  —  Xy.W-.  The  normal  evaluation  tree  has  cost  0  while  self-interpretation  uses  the  (BETA)  rule  once.  The 
applied  function  is  Xz.z  which  has  size  2,  so  we  have  what  we  need. 

N  =  Ni  N2.  Assuming  the  subtrees  have  costs  ki  and  jfc2  respectively,  the  total  cost  of  normal  evaluation  is 
ki  +k2+s,  where  s  is  the  size  of  unfold{Xv.Nz,  p").  By  induction,  the  cost  for  the  subtrees  for  self-interpretation 
are  at  most  4jfci  -t-  2  and  4A:2  -b  2.  The  tree  uses  (BETA)  twice,  once  for  the  function  Xz.z  (size  2)  and  once  for 
unfoldjXv.Ns,  p")  =  Xv.unfoldjNz,  /o")[a\J][6\/]. 

Since  the  size  of  unfold{Nz,  p")[a\i][6\/]  is  strictly  less  than  4  times  the  size  of  unfold{Nz,  p"),  we  have  that 
the  size  of  Xv.unfold^Ns,  /9")[o\/][6\/]  is  at  most  i\unfold{N3,  p")\  —  1  -I- 1  =  i{s  —  1).  Hence,  we  have  a  total 
cost  bounded  by  4fci  +  2  +  4^2  -f  2  -)-  2  4-  4(s  -  1)  <  4(A;i  -I-  /d2  +  s)  -f  2,  which  is  what  we  needed. 

□ 

By  combining  lemma  4  with  the  start-up  cost  of  7|M|  -f  8,  we  get  the  theorem 

Theorem  2.  If  a  closed  term  M  via  the  call-by-name  semantics  evaluates  to  a  WHNF  in  cost  c,  selfint  \M] 
evaluates  to  a  WHNF  in  cost  at  most  4c -t-  7\M\  -1-10. 

The  start-up  cost  proportional  to  the  size  of  M  is  unavoidable,  regardless  of  how  lambda  terms  are  rep¬ 
resented  and  how  the  self-interpreter  works.  We  required  representations  to  be  in  normal  form,  so  to  perform 
any  evaluation  that  depends  on  the  representation,  we  will  have  to  apply  the  representation  to  one  or  more 
arguments,  which  by  our  measure  has  a  cost  proportional  to  the  size  of  the  representation,  which  can  not  be 
less  than  linear  in  the  size  of  the  term. 

2.2  Environment-based  cost 

Another  common  method  for  implementing  call-by-name  lambda  calculus  is  using  environments  and  closures, 
much  as  indicated  by  the  inference  rules.  The  cost  measure  used  for  an  environment  based  implementation 
depends  on  how  the  environments  are  implemented.  Typical  data  structures  for  environments  are  linked  lists 
and  frames. 

Using  a  linked  list,  a  new  variable  is  added  to  the  front  of  the  list  at  unit  cost,  but  accessing  a  variable  equires 
a  walk  down  the  linked  list  and  hence  has  a  cost  that  depends  on  the  position  of  the  variable  in  the  environment. 
With  the  chosen  interpreter,  we  can  not  get  linear  time  self-interpretation  if  linked-list  environments  are  used, 
as  looking  up  the  two  specail  variables  a  and  b  has  a  cost  that  depends  on  the  size  of  the  environment,  which 
again  depends  on  the  size  of  the  program. 

If  frames  are  used,  a  new  extended  copy  of  the  environment  is  built  every  time  a  new  variable  is  added  to 
it.  This  has  cost  proportional  to  the  size  of  the  built  environment,  but  accessing  a  variable  in  the  environment 
is  now  using  aconstant  offset  from  the  base  of  the  frame,  which  is  unit  cost.  We  shall  see  below  that  we  can  get 
linear  time  self-interpretation  when  frames  are  used  to  represent  environments. 

Our  cost  measure  now  counts  each  use  of  the  (VAR)  or  (LAMBDA)  rule  as  1  and  each  use  of  the  (BETA) 
rule  as  the  size  of  the  new  frame,  i.e.  |p'l  -f  1. 

We  first  note  that  the  cost  of  the  initial  part  of  the  evaluation  tree  is  8.  We  then  state  and  prove  the  following 
lemma: 

Lemma  5.  If  derivation  of  p\- N  {Xy.W,  p')  has  cost  c,  then  derivation  ofp\-N  {Xy.W,  p’)  has  cost  at 
most  8c. 
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N  =  x:  Both  normal  evaluation  and  self-interpretation  use  the  (VAR)  rule  once,  so  if  the  cost  of  evaluating 
t  e  contents  of  the  variable  is  k,  the  total  evaluation  cost  is  A:  +  1.  By  induction,  self-interpretation  of  the 
contents  costs  at  most  8k,  for  a  total  self-interpretation  cost  of  8k  +  1,  which  is  less  than  the  8{k  +  1)  limit 

evaluation  tree  has  cost  1,  for  a  single  use  of  the  (VAR)  rule.  Self-interpretation 
uses  (VAR)  and  (LAMBDA)  twice  each  and  the  (BETA)  rule  once.  The  size  of  the  expanded  environment  is  2 
so  we  have  a  total  cost  of  6,  which  is  less  than  8  times  the  cost  of  normal  evaluation. 

=  ^  =  ^1  ^2:  Assuming  the  subtrees  have  costs  k^  and  *2  respectively,  the  total  cost  of  normal  evaluation 

IS  1  -b  A;2  -I-  Ip  I  -I-  1  By  induction,  the  cost  for  the  subtrees  for  self-interpretation  are  at  most  Sfci  and  Sfe. 
The  tree  uses  (VAR)  twice,  (LAMBDA)  once  and  ^E^)  twice,  once  for  the  function  Xz.z  (where  the  size  of 
the  expanded  environment  is  2)  and  once  for  {Xv.N^,  p").  Since  =  |p"|  +  2,  the  total  cost  is  bounded  by 
8*1  -t-  8A:2  +  2  -b  1  +  2  -b  Ip  I  -b  3  -  8A;i  -b  8A:2  +  |p"|  +  8,  which  is  less  than  the  budget  of  8(A:i  +  k2  -b  |p"|  +  1). 

By  adding  the  start-up  cost  of  8  to  the  cost  found  in  lemma  5,  we  get: 

^  evaluates  to  a  WHNF  in  cost  c  (using  the  environment-based  cost  function), 
seljint  I M I  evaluates  to  a  WHNF  in  cost  at  most  8c  +  8. 

3  Linear  time  self-interpretation  using  call-by- value  reduction 


We  define  call-by-value  reduction  by  the  inference  rules 
pb  Xx.M  {Xx.M,  p)  (LAMBDA ) 


phx=^p{x)  (VARV) 


p\-M  ^  {Xx.M',  p')  p\-N=^V  p'\xh^V]\-M'  W 

p\~  M  N  ^  W 


(BETAV) 


derivation  of  the  initial  stages  of  self-interpretation.  We  will  slightly  change  definition  of  p 
to  reflect  that  variables  are  bound  to  values,  ie.,  (closures  of)  terms  in  WHNF: 


—  _ _  »  " 

p[x^iXx.P,p')]  =  p[x^-^{Xx.P,'^)] 

We  first  define  a  simulation  lemma  for  call-by-value; 

inference  rules,  can  derive  p\-N  {Xy.W,  p')  then  we  can  also  derive 

which  we  prove  in  figure  2. 

Again  we  asjgn  different  costs  to  the  rules  to  obtain  linear-time  self-interpretation  results.  We  start  by 
counting  beta-reductions.  uy 

cailly^Me”"  “““  ^  ‘*’®  'emainder  we  use  a  lemma  like  the  one  for 

'''™f ""  then  oall-hy-valu,  derim- 

tion  0/  phiV  =»  (Ay.vr ,  p')  uses  at  most  4n  -b  1  beta-reductions. 

We  will  use  the  structure  of  lemma  6  for  proving  this 
N  =  x:  Neither  normal  evaluation  nor  self-interpretation  use  beta  reductions. 

once,  gTyinglo ^r^'we^^neSS*™”  ““  s«lf-tah*rpretation  usee  the  (BETA)  rale 

rpHiw”  subtrees  use  ki,  k^  and  k^  beta  reductions  respectively,  the  total  number  of 

S  mrThTlTh  ^  '■  fa  ^Wnterpretron  u°e 

y  1  +  2  +  +  5  —  4(fci  +  A:2  -f-  A:3  -}- 1)  -j-  which  is  what  we  want. 

By  adding  the  cost  for  the  initial  states  of  self-interpretation,  we  get:  ^ 

leZZtt'aWmFf  “T  "  o  heta  reduction,,  selfint  [M] 

evaluates  to  a  WHNF  using  at  most  4n  +  4  call-by-value  beta  reductions. 
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We  prove  lemma  6  by  induction  over  the  evaluation  tree  with  N  at  its  root: 

N  =  x-. 

Normal  evaluation:  pl-a;  =^(Ay.W,  Self-interpretation:  p\-x  =^{\y.W ,  p') 

N  =  Xy.W:  p\-N=i^  (Xy.W,  p)  is  a  leaf  tree.  N  =  h  (Ay.W),  so  we  get 

pl-6  =»(Az.2:,pi)  pt[zi^ {Xy.W ,p)\^ z  :^{\y.W,p) 
p^b  (XyW)  =i^{Xy.W,p) 

N  =  Ni  Nz:  The  normal  evaluation  tree  is 

phNi  =^{Xv.N3,p")  p^Nz  ^  {XW.N4, p"')  p"[vi-i-{Xw.N4,p*")]l~ Ns  =i~{Xy.W,p') 
■“  phJVi  Nz  =^(Xy.W,p') 

We  have  =  a  Ni  TTz,  so  we  get  (by  induction)  the  following  tree  for  self-interpretation 


phNz  =^{Xw.N4,  p'")  p"{^)^4(A^l;.iV4|  p'")]l-A3  =»(Ay.W,  p') 
pho  Ni  Nz  =>{Xy.W,  p') 


where  (*)  is  the  tree 


p|-a=^^(A^.2:,pi)  p,[z^{Xv.N^,p")]hz^{Xv.Nz,p") 

pha  Ni  =^{Xv.Nz,  p^ 

Fig.  2.  Proof  of  lemma  6 


3.1  Substitution-based  cost 

Again  we  want  to  base  the  cost  of  a  beta  reduction  on  the  size  of  the  function,  and  again  we  consider  a  value 
(Xy.P,p)  to  represent  the  term  unfold{Xy.P,p).  We  need  a  variant  of  lemma  3,  using  the  new  definition  of  p. 
We  do  not  get  equality,  as  we  did  in  lemma  3,  as  some  terms  T  may  be  replaced  by  (/  T).  We  define  P  :<  Q 
to  mean  that  some  subterms  T  in  P  may  be  replaced  by  (/  T)  in  Q  and  use  this  in  the  definition  of  the  new 
lemma.  Note  that  size  of  P  is  no  larger  than  the  size  of  Q. 

Lemma  8.  unfold(Ai/.P,  p)  Ay.unfold(F, p)[a\7][i>\7]. 

where  P  means  that  some  subterms  T  in  P  may  be  replaced  by  (J  T)  in  Q.  Hence,  the  size  of  P  is  no 
larger  than  the  size  of  Q.  We  prove  lemma  8  similarly  to  the  way  we  proved  lemma  3: 
unfold{Xy.P,  [])  =  Xy.P: 

unfold{Xy.P,^ 

=  unfold{Xy.P,  ps) 

=  unfold{Xy.P,p2)[b\unfold{I,pi)] 

=  unfoldlxy.P,p2)[b\I] 

=  unfold{Xy.P[a\unfoldiI,pi)],  D)[?'\f] 

=  Xy.P[a\I][b\I] 

unfold(Xy.P,  p[xt-^{Xz.Q,  p')])  =  unfold{Xy.P,  p)[x\unfold{Xz.Q,  p")]: 

unfold{Xy.P,p[xt^{Xz.Q,  p')]) 

=  unfold{Xy.P,p[xi->-{Xz.Q,f^)]) 

by  definition  of  p 

=  unfold{Xy.P,p)[x\unfold{Xz.Q,  p')] 

by  definition  of  unfold 

:<  Xy.unfold{P,p)[a\I][b\I][x\Xz.unfold{Q,rho')[a\r\[b\I]] 

by  induction 

—  Xy.unfold{P,p)[x\Xz.unfold{Q,rho')][a\I][b\I] 

H  Xy.unfold{P, p)[x\unfold{Xy.Q, r/!o')][a\7][6\7] 
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Since. the  Size  of  is  strictly  less  than  4  times  the  size  of  P,  we  see  that  \unfold{\y:P,p)\  < 

\\y.unfold{P,  p) [a\7] [b\I]  1  <  1  +  4| unfold{P,  p) | .  \  J  \  n  - 

the  tree  to  be  at  most  7\M\  +  8,  just  aa  for  the  call-by-name  cas^ 

tor  the  rest,  we  use  the  lemma 

^  '•'«  “»<«.  then  call-by-vahe  derivation  offri 

•'''  ^  \^y-vV ,  p')  has  cost  at  most  5c +  2.  ^ 

Proof: 

N  =  x:  Both  normal  evaluation  and  self-interpretation  has  cost  0. 

^  -  >^y-W:  The  normal  evaluation  tree  has  cost  0  while  self-interpretation  uses  the  (BETA )  rule  once  for 

thetermA^.z,  which  has  size  2,  giving  5- 0-f  2,  as  we  needed.  ruie  once  tor 

is  h  the  subtrees  have  costs  fci,  k2  and  kg  respectively,  the  total  cost  of  normal  evaluation 

•  ^  3  +  s,  where  s  is  the  size  of  unfold{\v.N^,  p").  By  induction,  the  cost  for  the  subtrees  for  self 

interpretation  are  at  most  5A:H-  2.^5^.^+  2  and  5^3  +  2.  The  tree  uses  (BETA)  twice,  once  for T/  wS 

what  we  w^nt.'  ®  +  ^2  +  Ajg  +  s)  -h  4  -  s.  Since  the  smallest  possible  value  for  s  is  2,  we  have 

Combined  with  the  initial  cost  of  7|M|  -|-  8,  we  get 

Theorem  5.  If  closed  term  M  evaluates  by  call-by-value  to  a  WHNF  in  cost  c,  selfint  \M]  evaluates  by 
call-by-value  to  a  WHNF  in  cost  at  most  5c  4-  7\M\  + 10.  !  I  ■  2/ 


3.2  Environment-based  cost 

'“"-‘■J-"™'-  The  cos.  of  the  initial  section  of  the  tree 

is  used.  We  prove  this  as  before 

N  —  x:  Both  normal  evaluation  and  self-interpretation  has  cost  1 

rnIel«''fora“ZT77Sl™  t,”  ‘“7T‘  '  “''-"terp^tation  uses  (VAR)  twice  and  the  (BETA ) 

belorthe  hLl!  expanded  environment  is  of  site  2,  giving  a  total  cost  of  4.  This  is  well 

is  h.'+fc+L+’l'neiTl'TJtd'  have  costs  fci,  h,  and  hj  respectively,  the  total  cost  of  normal  evaluation 

The  tree  uses  (VAR)  and  I'BBrdTt  self-interpretation  are  at  most  7fe,  7fe  and  rk,. 

hi  1  7  w-7  /  I  ^.T,“  <“*'  2)  and  once  for  (An.TV,,^).  which 

which  t  whit  ™  iiil  '  “  +  V\TT<  7(h.  AkaAhA  |p“|  -hi), 

Combined  with  the  initial  cost  of  9,  we  get 


Theorem  6.  //a  closed  term  M  evaluates  by  call-by-value  to  a  WHNF  in  cost  c 
cost),  selfint  [M]  evaluates  by  call-by-value  to  a  WHNF  in  cost  at  most  7c -f  9. 

4  Call-by-need  reduction 


(using  environment-based 


Describing  call- by-need  reduction  by  a  set  of  inference  rules  is  not  as  easy  as  for  call-by-name  or  call  bv  value 
Imnlf  threaded  through  the  evaluation  and  used  for  updating  closures.  This  is,  however  rather 

applLtionmTetTtht  nondeterministic  by  adding  an  alternative 

pl-M  =»  {Xx.M',  p')  pi[x)-^,]\-M' =>  W 

phM  N=^W  '  (DUMMY) 

foser/ff  rule  from  teh  call-by-value  semantics  evaluates  the  argument,  the  (DUMMY)  rule  doesn’t  but 
inserts  a  dummy  value  •  in  the  environment  instead  of  the  value  of  the  argument.  There  is  no  rule  rafa  low 
.  m  computations,  so  choosing  the  latter  application  rule  will  only  lead  to  In  answer  if  the  vllt  notn^W 
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We  prove  lemma  11  by  induction  over  the  evaluation  tree  with  N  at  its  root.  Only  the  case  for  the  (DUMMY)  rule  differs 
from  the  proof  of  lemma  6,  so  we  omit  the  rest. 

N  =  Ni  iVij;  Using  the  (DUMMY)  rule,  the  normal  evaluation  tree  is 


These  rules  model  both  call-by-need,  call-by-value  and  everything  in-between.  We  can  define  a  partial  order 
on  inference  trees  for  the  same  expression  by  saying  that  a  tree  Ti  is  less  than  a  tree  if  T2  uses  the  (BETAV) 
rule  whenever  Tx  does.  The  least  tree  in  this  ordering  that  computes  a  non-*  result  corresponds  to  call-by-need 
reduction  to  WHNF.  Hence,  we  have  moved  parts  of  the  operational  behaviour  of  the  language  to  the  meta-level 
of  the  semantic  rules,  rather  than  in  the  rules  themselves. 

This  characterization  of  call-by-need  may  not  seem  very  operational.  However,  a  process  that  builds  a  mininal 
evaluation  tree  may  mimic  traditional  implementations  of  call-by-need:  When  an  application  is  evaluated,  the 
(DUMMY)  rules  is  first  used.  If  it  later  turns  out  that  the  argument  is  in  fact  needed  (when  a  use  of  a  •  is 
attempted),  the  origin  of  the  •  is  traced  back  to  the  offending  (DUMMY)  rule.  This  is  then  forcibly  overwritten 
with  a  (BETAV)  rule  and  the  sub-tree  for  the  argument  constructed.  When  this  is  done,  the  •  is  replaced  by 
the  correct  value  and  computation  resumed  at  the  place  it  was  aborted.  Hence,  *’3  play  the  role  of  suspensions 
and  the  replacement  of  a  (DUMMY)  rule  by  a  (BETAV)  rule  corresponds  to  updating  the  suspension. 

The  initial  part  of  self-interpretation  for  call-by-need  is  the  same  as  for  the  call-by-value  case,  except  that 
for  simple  terms,  the  variables  a  or  6  may  not  be  needed  and  can  hence  be  bound  to  •  and  the  corresponding 
evaluations  of  their  closures  not  occur.  However,  the  cost  of  the  initial  portion  will  (by  any  reasonable  cost 
measure)  be  no  more  than  the  cost  of  the  call-by-value  tree.  We  will  use  the  same  initial  environments  as  for 
the  call-by-value  case,  but  extend  the  definition  of  p  to  handle  variables  that  are  bound  to  *. 

n  _ =  P3  _ 

p[xh-^{\x.P,p')]  =  p[a;t-»-(Aa:.F,/9')] 
p[x  i->  •]  =  p[a:  »->  •] 

Like  in  the  previous  cases,  we  define  a  call-by-need  simulation  lemma: 

Lemma  using  the  call-by-need  inference  rules  can  derive  p\-N  ^  (Ay.W,  p')  then  we  can  also  derive 

p\-N  =»  {Xy.W,  p'). 

Which  we  prove  in  figure  3. 

Since  lemma  11  includes  the  cases  where  variables  in  the  environment  are  bound  to  *,  we  conclude  that,  if 
normal  evaluation  does  not  need  the  value  of  a  variable,  then  neither  does  the  self-interpreter. 

We  will  in  the  proofs  of  linear-time  self-interpretation  also  refer  to  the  proofs  for  the  call-by- value  case  except 
for  the  (DUMMY)  case,  as  we  use  the  same  cost  measures  and  the  same  constant  factors. 

We  start  by  counting  beta  reductions.  Our  theorem  is 

Theorem  7.  If  a  closed  term  M  via  the  call-by-need  semantics  evaluates  to  a  WHNF  using  n  call-by-need  beta 
reductions,  selfint  \M]  evaluates  to  a  WHNF  using  at  most  4n  -f  4  call-by-need  beta  reductions. 

The  corresponding  lemma  proves  simulation  using  4n-|- 1  steps,  after  the  initial  portion.  We  use  the  proof  for 
lemma  7  with  the  addition  of  a  case  for  the  (DUMMY)  rule:  Normal  evaluation  uses  fci  -f-feg  -i- 1  beta  reductions. 
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^ere  fci  aad  fcg  are  the  numbers  of  beta  reductions  required  for  and  Ns.  By  induction,  interpreting  and 
^3  costs  at  most  +  1  and  4*2  +  1.  Additionally,  2  beta  reductions  are  used,  so  the  total  cost  is  bounded  by 
+  *2  +  1),  which  IS  one  less  than  our  limit. 

to  substitution-based  cost.  We  assign  the  same  cost  to  the  (DUMMY)  rule  as  to  the 
(DhlAV)  rule:  The  size  of  the  extended  environment. 

We  extend  the  definition  of  unfold  to  handle  •: 

unfold{P,p[xH-»])  =  unfoldiP,p)[x\d\ 

where  d  is  a  free  variable  that  does  not  occur  anywhere  else.  It  is  easy  to  see  that  the  same  size  limit  as  before 
applies.  \unfold{Xy.P,p)\  <  4\unfold{P, p)\.  Hence,  we  shall  go  directly  to  the  theorem 

Theorem  8.  If  a  closed  term  M  evaluates  by  call-by-need  to  a  WHNF  in  cost  c,  selfint  [M)  evaluates  bv 
call-by-need  to  a  WHNF  in  cost  at  most  5c  +  7|M|  +  10.  >  J  \  I  evaluates  oy 

Agaan,  we  only  state  the  case  for  the  (DUMMY)  rule  and  refer  to  lemma  9  for  the  rest:  If  normal  evaluation 
has  cost  *1  and  *3  for  evaluation  of  iVi  an_^iV3,  tlm  total  cost  is  *i+*2+s,  where  s  is  the  size  oiunfoMXv.No  p"). 
or  se  f-mterpretation  interpretation  of  Ni  and  Ns  have  by  induction  costs  bounded  by  5*i  +2  and  5*3+2’  Ad- 
dition^ly  we  use  (BETAV)  once  at  cost  2  and  (DUMMY)  once  at  cost  \unfold{XvJh,W)\  <  A\unfoldik  p")\  = 
4(s  -  1).  This  gives  a  total  cost  bounded  by  5(*i  +  *2  +  «)  -  s  +  2,  which  is  well  within  our  limit, 
tnvironment-based  cost  is  no  bigger  problem: 

//«  closed  termM  evaluates  by  call-by-need  to  a  WHNF  in  cost  c  (using  environment-based  cost), 
selfint  [M]  evaluates  by  call-by-need  to  a  WHNF  in  cost  at  most  7c  +  9. 

to  t”  proof  of  lenuna  10 

NormtJ  evaluation  uses  the  (DUMMY)  rule  at  cost  |p»|  +  1  plus  the  costs  of  evaluating  and  JV3,  which 

f/TJaf  f”  ““  “*  ^  To  this  we  add  two 

uHo  70^  rf  ^  t"**  *'''  ““  at  cost  |^P|  +  1  =  \„"\  +  3.  This  adds 

up  to  ({ki  +  *3  +  IP  I  +  1)  -  6jp"|,  which  is  within  our  budget. 

5  Conclusion  and  future  work 

We  have  proven  that  a  simple  self-interpreter  for  the  pure  lambda  calculus  can  do  self-interpretation  in  linear 
time,  *.e.  constant  overhead.  We  proved  this  for  reduction  to  weak  head  normal  form  using  call-by-name  call- 
by-value  and  call-by-need  using  three  different  cost  measures. 

tri  be  interesting  to  extend  the  present  work  to  include  studies  of  self-interpretation  cost  for  reduction 

but  normal  form.  The  author  expects  thefee  to  have  linear-time  self-interpretation  too, 

but  IS  not  currently  working  on  proving  this. 

f  interesting  in  its  own  right,  the  result  is  a  step  towards  proving  the  existence  of  a  linear¬ 

time  complexity  hierarchy  for  the  pure  lambda  calculus,  along  the  lines  of  Jones’  result  for  first-order  functional 
languages  [2]  The  proof  involves  a  self-interpreter  that  not  only  has  constant  overhead  but  also 
Sntlf  7  T  f  measure)  it  uses.  If  it  can  not  finish  within  a  set  budget  of  time 

f  with  a  special  error-value.  This  self-interpreter  is  then  used  in  a  diagonaliLtion  proof 
eminiscent  of  the  classical  halting-problem  proof  to  show  that  a  certain  problem  can  be  solved  in  time  o(kn) 
but  not  in  time  o(n),  where  *  is  the  interpretation  overhead.  ^  ^ 

We  ^e  currently  working  on  this  and  have  sketched  a  proof  for  call-by-name  reduction  to  WHNF.  However 
due  to  the  resource  counting  the  proof  is  about  an  order  of  magnitude  harder  than  the  proofs  shown  in  this 
paper,  so  we  are  investigating  ways  to  simplify  the  proofs. 

for  CAM  7fabs?r7r  ^  linear-time  hierarchy 

r  CAM  an  abstrart  machine  used  for  implementing  higher-order  functional  languages.  This  was  proven  by 

TUx  method  does 

It  ”tot2  7t  f7  '*“'““"36  oeccesary  conditions  for  the  erdstence  of  a  lineai-time  hierarchy. 

a  nL  2mt7n,™h“  T”'’!  “  “craiohy  it  may  not  allow  constanWime  access  to 

a  non-constant  number  of  variables,  locations,  symbols  or  functions,  where  the  constant  is  uniform  over  all 
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programs.  This  would  indicate  that  any  cost  measure  for  the  lambda  calculus  that  allow  constant  time  access  to 
variables  (e.g.  counting  beta-reductions)  contradics  the  existence  of  a  linear-time  hierarchy.  However,  the  proof 
sketch  mentioned  above  indicates  that  one  such  actually  does  exist.  We  will  look  further  into  this  apparent 
contradiction  in  future  work. 

In  [4],  a  different  representation  of  lambda  terms  was  used.  It  was  based  on  higher-order  abstract  syntax, 
but  used  a  standard-style  representation  where  recursion  over  the  syntax  is  not  encoded  in  the  term  itself. 
Hence,  the  self-interpreter  needed  to  use  an  explicitly  coded  fixed-point  combinator,  making  it  somewhat  more 
complex  than  the  one  used  in  this  paper.  Redoing  the  proofs  in  this  paper  for  that  self-interpreter  will  be  much 
more  work  due  to  the  larger  size,  but  the  same  principles  should  apply  and  we  expect  a  (much  larger)  constant 
overhead  for  this  case  as  well. 

The  use  of  a  nondeterministic  operational  semantics  to  encode  call-by-need  reduction  made  the  proofs  for 
this  very  simple.  In  our  knowledge,  this  technique  hasn’t  been  used  earlier,  though  a  similar  notion  (repacing  a 
term  by  •)  has  been  used  to  define  neededness  [1].  We  expect  it  to  be  useful  for  proving  other  properties  about 
call-by-need  reduction. 

Our  discussion  of  different  cost  measures  may  seem  similar  to  the  discussions  by  e.g.  Lawall  and  Mairson  [3] 
on  cost  models  for  the  lambda  calculus.  However,  these  models  are  meant  to  be  independent  of  any  particular 
implementation  whereas  the  measures  presented  here  try  to  mimic  specific  implementation  methods. 
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1  Regular  Schemes 


In  the  following,  we  assume  that  sets  of  variables,  basic  statements,  and  selectors  are  given.  Let  us  choose 
subsets  of  arguments  A{s),  results  R{s),  and  obligatory  results  R'{s)  C  R{s)  in  the  set  of  variables  for  each 
basic  statement  s.  For  each  selector  c,  we  choose  the  set  of  its  arguments  A{c).  The  sets  of  results  and  obligatory 
results  for  selectors  are  considered  to  be  empty.  In  addition,  an  arity  ar{c)  €  N  is  assigned  to  each  selector  c. 

Regular  schemes  (hereafter,  schemes)  are  directed  ordered  labeled  graphs  of  a  special  kind.  The  set  of  schemes 
can  be  inductively  described  as  follows. 

1.  The  graph  with  the  empty  set  of  nodes  and  arcs  is  a  scheme:  this  is  an  empty  scheme.  For  any  nonempty 
scheme  5,  we  will  indicate  two  distinguished  nodes  —  the  input  and  the  output. 

2.  A  graph  without  arcs  with  the  single  node  v  labeled  by  a  basic  statement  s  is  a  scheme:  this  scheme 
corresponds  to  the  basic  statement  s  and  has  node  v  as  its  input  and  output. 

3.  Let  5i  and  S2  be  nonempty  schemes.  Connect  the  output  of  Si  with  the  input  of  ^2  by  a  new  arc.  Let 
the  input  of  Si  be  the  input  of  graph  S  constructed  in  this  way,  and  the  output  of  S2  be  its  output.  Extend 
the  order  of  S  by  the  relation  of  the  new  arc  with  itself.  Then,  the  graph  S  is  a  scheme:  we  will  say  that  S  is 
obtained  from  Si  and  S2  by  the  series  union  and  write  it  as  S'  =  ^i  o  6^2  • 

4.  Let  .0  be  a  scheme,  c  be  a  selector,  and  ar(c)  ==  2.  Consider  two  new  nodes  v  and  w  —  the  input  and 
the  output  of  a  new  scheme  S,  respectively.  Let  us  label  w  by  the  selector  c  and  connect  w  and  u  by  a  new  arc 
ihen,  we  act  as  follows.  If  B  is  nonempty,  we  connect  v  with  the  input  of  0  by  a  new  arc,  and  the  output  of 
0  with  w,  by  another  new  arc.  If  0  is  empty,  we  connect  v  and  m  by  a  new  arc.  For  each  new  arc,  we  extend 

e  order  of  S  by  the  relation  of  this  arc  with  itself.  Graph  S,  constructed  as  described  above,  is  a  scheme:  we 
will  say  that  S  is  the  loop  with  the  body  0  and  the  condition  c. 

5.  Let  01  . .  0„  be  regular  schemes,  c  be  a  selector,  and  ar(c)  =  n.  Consider  two  new  nodes  v  and  w  — 

the  input  and  the  output  of  a  new  scheme  S,  respectively.  Let  us  label  v  by  the  selector  c.  Then,  we  act  as 
follows.  For  each  nonempty  scheme  0^,  we  connect  0  with  the  input  of  0^  by  a  new  arc,  and  the  output  of  0. 
with  w,  by  another  new  arc.  For  each  empty  scheme  0*,  we  connect  v  and  ui  by  a  new  arc.  For  each  pair  of  new 
arcs  with  the  common  beginning  and  belonging  to  schemes  0^  and  Bj,  respectively,  extend  the  order  of  S  by 

e  relation  between  these  arcs  if  i  <  j.  Graph  S  constructed  as  described  above  is  a  scheme:  we  will  say  that 

is  the  hammock  with  the  selector  c  and  the  branches  0i,  . . .,  0„. 

A  scheme  is  called  a  component  if  it  is  nonempty  and  cannot  be  represented  in  a  form  of  the  series  union  of 
two  nonempty  schemes. 

.  We  now  define  the  sets  of  arguments  A(5),  results  R{S),  and  obligatory  results  0'(5)  for  scheme  5.  A  path  in 
a  regular  scheme  is  a  sequence  vid  . . .  consisting  of  nodes  Vi,...,Vn  and  arcs  ei ,  . . .,  e„_i  in  which 

tne  arc  leads  froin  Vi  to  Vi+i .  An  execution  chain  in  a  regular  scheme  is  a  sequence  of  labels  written  down  when 
going  along  a  path  from  the  input  to  the  output.  For  an  execution  chain  a,  let  us  set  A(a)  -  R(a)  =  R'(a)  =  0 
if  a  is  empty,  and  A(a)  =  A(ai)  U  (^(aj)  \  0'(ai)),  0(o)  -  R{ai)  U  0(02),  R'{a)  =  R'{ai)  U  R'{a2),  if  a  can 
be  represented  as  a  concatenation  of  subchains  ai  and  02  at  least  one  of  which  is  nonempty. 

If  S  is  empty,  we  set  A(S)  =  0(5)  =  0'(5)  =  0.  Now  assume  that  5  is  nonempty.  Let  EC(H)  be  the  set  of 
all  execution  chains  of  5.  Then  A (5)  =  U.e.c(S)  A(a),  0(5)  =  U...c(S)  -d"  =  nLc^  TiX 

of  thf  .L  ^  m  f  ^  -5  i  a  result 

?elMtofs„b?cheJe  f  =  S[r/r)  is  obtained  from  S  by 

^‘ermlned  by  the  set  of  values  of  all  variables  or  is  an  invalid  state.  An  interpmtation 
‘ransformation  of  memory  states  to  each  basic  statement;  interpretation  also  assigns  to 
each  selector  a  function  that  generates  a  number  of  the  branch  to  be  chosen,  dependiig  on  the  memory  state! 
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or  generates  an  error  message.  Once  an  interpretation  is  specified,  it  can  be  extended  on  the  set  of  all  regular 
schemes  in  a  natural  way.  Two  schemes  are  called  equivalent  if  any  interpretation  assigns  them  identical  functions. 

A  regular  scheme  S  is  called  a  pseudoscheme  if  the  parent  scheme  par{S)  and  the  sets  of  candidates  for 
deletion  after  the  removal  up  or  down,  u-dels{S)  and  d-dels{S),  are  specified. 

An  execution  chain  a  is  called  irredundant  if  it  cannot  be  represented  in  the  form  of  the  concatenation  of 
three  subchains  a  =  aia2a3,  in  such  a  way  that  t  €  R(cx2),  t  G  i?'(a3),  t  ^  A(q;2),  and  t  ^  A{a3)  for  some 
variable  t.  A  scheme  S  is  irredundant  if,  for  any  of  its  arc,  there  exists  an  irredundant  execution  chain  obtained 
from  a  path  involving  this  arc.  If  a  scheme  is  irredundant,  any  of  its  subscheme  is  also  irredundant. 

2  Removal  from  Loops  and  Hammocks 


Let  L  be  a  subloop  of  a  scheme  S  with  a  body  B  —  XoXoX  and  a  condition  c,  where  X_,  X,X  be  regular 
schemes,  and  A  be  a  component.  If  the  cdndit^s  of  removal  up  from  L  A{X)  n  R{X)  =  R(X)  Pi  A{X)  = 
R{JO  n  R{X)  n  (A(A)_U  (A(c)  \  R'{^))  =  RiX)  D  R{X)  \  A{X)  n  R(X  o  A  o  X)  =  0,  and  either 

(A(A  o  A)^ (A(c)  \R'iXo  A)))  n  i2(A  o  A  o  A)  =  0  or  R{X)  n  I?" (A  o  A)  =  RiX)  fl  iZ'(A  o  A)  n  (A(A  o  A)  U 
(A(c)  \  R'iX  o  A)))  =  0,  hold  for  A,  the  removal  up  of  A  from.  L  consists  in  the  substitution  of  scheme  A  o 
for  subloop  L.  If  the  condition^  of  removal  down  from  L  A(A)  n  RiX)  =  RiX)  D  (A(A)  U  (A(c)  \  R'iX)))  — 
RiJQ  n  RiX)  =  i?(A)  n^(A(A  o  A)  ^(A(c)  \  R'iX  o  A)))  ==  0,  ^d  either  A(A)  n  i?(A  o  A  o  A)  =  0  or 
(A(A  o  A)  U  (A(c)  \  R'iX  o  A)))  D  i?(A  o  A)  =  A(A)  n  i(A)  \  R'iX  o  A)  =  0,  hold  for  A,,  the  removal  down 
of  A  from  L  consists  in  the  substitution  of  scheme  L^x)  °  X  for  subloop  L. 

Let  A  and  Y  be  linear  subcomponents  of  B.  We  say  that  the  removal  up  of  Y  depends  on  the  removal  up  of 
A  and  write  A  ->■„  Y,  if  A  is  arranged  before  Y  m  B,Y  is  not  a  pseudoscheme  with  pari)Y)  =  A,  and  one  of 
the  intersections  A(A)  D  i?(F),  RiX)  D  A(F),  or  i?(A)  n  R(X)  is  not  empty,  or  A  =  F  and  A(F)  n  RiX)  #  0, 
or  A  is  arranged  after  F  in  .B  and  one  of  the  intersections  A(F)  D  i?(A),  or  i?(F)  n  B(A)  is  not  empty.  We 
say  that  the  removal  down  of  F  depends  on  the  removal  down  of  A  ^nd  write  A  F,  if  one  of  the  following 
conditions  A  is  arranged  after  F  in  B,  F  is  not  a  pseudoscheme  with  par(F)  =  A,  and  one  of  the  intersections 
A(F)  n  RiX),  B(F)  n  A(A),  or  B(F)  n  B(A)  is  not  empty,  or  A  ==  F  and  A(F)  D  B(F)  7^  0,  or  A  is  arranged 
before  F  in  B  and  one  of  the  intersections  B(A)  D  A(F),  A(A)  D  B(F),  or  R'iX)  n  B(F)  is  not  empty.  We  say 
that  the  removal  down  of  F  depends  on  the  selector  c  and  write  c  F,  if  A(c)  n  B(F)  7^  0. 

We  define  a  removal  dependency  graph  AX)  as  follows.  The  set  of  nodes  consists  of  the  selector  c  and  all 
the  linear  subcomponents  of  B.  The  set  of  arcs  is  divided  in  two  nonoverlapping  sets  of  u-arcs  and  d-arcs,  in 
such  a  way  that  u-arc  e  connects  nodes  v  and  w  if  and  only  if  v  w,  and  d-arc  e  connects  nodes  v  and  w  if 
and  only  if  v  w.  Let  deg'^iv)  be  the  number  of  u-arcs  with  the  end  node  v,  and  deg’J(u)  be  the  number  of 
d-arcs  with  the  end  node  v. 

Let  B  be  a  hammock  with  a  selector  c  and  branches  Bi,  . . Bn.  A  candidate  chain  for  removal  up  from  H 
is  a  sequence  A  =  Ai,  . . .,  A„  of  mutually  isomorphic  schemes,  such  that  A,  is  a  linear  subcomponent  of  Bi  and 
the  number  of  linear  subcomponents  of  Bi  that  are  isomorphic  to  A,  and  are  arranged  in  Bi  before  Aj  is  the 
same  for  all  i.  Similarly,  a  candidate  chain  for  removal  down  from  B  is  a  sequence  A  =  Aj,  . . .,  Xn  of  mutually 
isomorphic  schemes,  such  that  A,  is  a  linear  subcomponent  of  Bi  and  the  number  of  linear  subcomponents  of 
Bi  that  are  isomorphic  to  Aj  and  are  arranged  in  Bj  after  A,-  is  the  same  for  all  i.  Let  us  designate  any  of 
the  schemes  Ai,  . . .,  Xn  as  Comm  (A)  and  the  hammock  obtained  from  B  by  deleting  all  schemes  Ai,  . . .,  A„ 
as  B(x)-  Let  A  be  a  candidate  chain  for  removal  (up  or  down),  and  ITu  i  =  1 . .  .n  he  the  subschemes  of 
B  such  that  B,-  =  ^  o  Aj  o  Aj  for  all  i.  If  A  is  a  candidate  for  removal  up  and  the  conditions  of  removal  up 
from  B  (A(c)  U  A(^))  n  B(Aj)  =  ROQ  n  A(Aj)  =  B(A^)  n  B(Ai)  n  A(^)  =  R(Xl)  n  B(Aj)  \  B'(^)  =  0  for 
all  i,  hold  for  A,  the  removal  up  of  chain  A  from  B  consists  in  the  substitution  of  scheme  (7omm(A)  o  B(x) 
for  hammock  B.  Similarly,  if  A  is  a  candidate  for  removal  down  and  the  conditions  of  removal  down  from  B 
A(Aj)  n  RjXj)  =  B(Aj)  n  AjXj)  =  B(Ai)  n  RjXj)  =  0  for  all  i,  hold  for  A,  the  removal  down  of  chain  A  from 
B  consists  in  the  substitution  of  scheme  B(x)  °  Comm(A)  for  hammock  B. 

Let  Aj  be  a  linear  subcomponent  of  Bi,  F  be  a  candidate  for  removal  up  from  B.  We  say  that  the  removal 
up  of  F  depends  on  Aj  and  write  Aj  F,  if  Aj  is  arranged  before  Fj  in  Bi,  F,  is  not  a  pseudoscheme  with 
parXi)  =  Aj,  and  one  of  the  intersections  A(Fi)nB(Aj),  B(Fj)ndi(Aj),  or  B(Fj)nB(Ai)  is  not  empty.  Let  A  be 
a  candidate  for  removal  up  from  B.  We  say  that  the  removal  up  of  F  depends  on  the  removal  up  of  A  and  write 
X  F,  if  Aj  -tu  F  for  all  i.  We  say  that  the  removal  up  of  F  depends  on  the  selector  c  and  write  c  F,  if 
Aic)  n  CommX))  ^  0.  Similarly,  let  Aj  be  a  linear  subcomponent  of  Bi,  F  be  a  candidate  for  removal  down 
from  B.  We  say  that  the  removal  down  of  F  depends  on  the  removal  down  of  Aj  and  write  Aj  F,  if  Aj  is 
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arranged  after  Fj  in  Bi,  Yi  is  not  a  pseudoscheme  with  por(yf)  =  Xi,  and  one  of  the  intersections  A(yj)ni?(Xi), 
R(Yi)  n  A{Xi),  or  -R(yj)  n  R{Xi).  Let  X  be  a  candidate  for  removal  down  from  H.  We  say  that  the  removal 
down  of  y  depends  on  the  removal  down  of  X  and  write  X  Y,  if  Xi  Y  for  all  i. 

We  define  a  removal  dependency  graph  A{H)  as  follows.  The  set  of  nodes  consists  of  the  selector  c,  candidate 
chains  for  removal  up  or  down  from  H,  and  all  the  linear  subcomponents  of  Bi,  . . Bn  that  do  not  belong  to 
any  of  candidate  chains.  The  set  of  arcs  is  divided  into  two  nonoverlapping  sets  of  u-arcs  and  d-arcs  in  such  a 
way  that  u-arc  e  connects  nodes  v  and  w  if  and  only  if  v  — w,  and  d-arc  e  connects  nodes  v  and  w  if  and  only 
if  V  ->d  w.  Let  deg+{v)  be  the  number  of  u-arcs  with  the  end  node  v,  and  degj{v)  be  the  number  of  d-arcs  with 
the  end  node  v. 

Y  X  =  Xi,  . . .,  Xn  is  a  candidate  chain  for  removal  up  or  down,  then  a  candidate  chain  Jt  for  removal  in 
opposite  direction  is  called  duol  to  X  if  for  some  i 

3  The  Purging  Algorithm 


Algorithm. 

Input:  a  regular  scheme  S- 

Output:  a  regular  scheme  5'. 

First,  procedure  1  is  applied  to  the  input  scheme  S.  It  constructs  a  scheme  S'  and  the  set  J7(5')-  Then, 
each  pseudoscheme  T  €  n{S')  is  transformed  to  an  ordinary  scheme  (additional  information  is  deleted)  and  all 
subschemes  belonging  to  the  set  u-dels{T)  are  deleted  from  S'  in  the  process. 

Procedure  1. 

Input:  a  regular  scheme  S. 

Outputs:  a  scheme  5' and  the  set  17(5'). 

1.  If  5  is  an  empty  scheme,  or  5  corresponds  to  a  basic  statement,  then  return  5  and  the  set  77(5)  =  0. 
Otherwise,  go  to  step  2. 

2.  If  5  is  a  loop,  then  go  to  step  3.  If  5  is  a  hammock,  then  go  to  step  4.  Otherwise,  let  5  =  5i  o  . . .  o  5„ 
n  >  2.  The  procedure  1  is  then  applied  to  schemes  5i,  . . .,  5„.  Let  5',  77(5(),  . ...,  5;,  77(5;,),  respectively,  be 
the  outputs  obtained.  Then,  return  the  scheme  5'  =  5(  o  . . .  o  5;,  and  the  set  77(5')  =  Uiefi  n] 

^  3.  Let  5  be  a  loop  with  a  body  B  and  a  condition  c.  The  procedure  1  is  then  applied*to  the  scheme  B.  Let 
B'  and  77 {B')  be  the  outputs  obtained,  and  S'  be  the  loop  with  the  body  B'  and  the  condition  c.  The  procedure 
2  is  then  applied  to  the  loop  S'  and  to  the  set  77(5')  =  II {B').  Let  5"  be  the  output  obtained.  Then,  return 
5"  and  the  set  77(5")  =  0. 

4.  Let  5  be  a  hammock  with  a  selector  c  and  branches  5i,  . . The  procedure  1  is  then  applied  to 
schemes  Bi,  ...,  Bn.  Let  77(B(),  . . .,  B'^,  II{B'n),  respectively,  be  the  outputs  obtained,  and  S'  be  the 
hammock  with  the  selector  c  and  branches  . . .,  S;,.  The  procedure  3  is  then  applied  to  the  hammock  5' 
and  to  the  set  77(5')  =  Ui6[i:n]  5"  and  77(5")  be  the  outputs  obtained.  Then,  return  5"  and  the 

set  77(5"). 

Procedure  2. 

Inputs:  a  loop  L  and  the  set  II(L). 

Output:  a  regular  scheme  L'. 

1.  Construct  the  graph  A{L).  Then,  transform  each  pseudoscheme  T  e  11  (L)  to  an  ordinary  scheme  and 
delete  from  S'  all  subschemes  that  belong  to  set  d-dels{T).  Set  M  ^  N  =  e.  Then,  go  to  step  2. 

2.  If  there  exists  at  least  one  scheme  X  such  that  deg'^  (X)  —  0,  select  this  scheme  and  go  to  step  3  Otherwise 

go  to  step  4.  ’ 

3.  Delete  the  node  X  and  all  arcs  that  begin  in  X  from  A{L).  Then,  delete  X  from  L,  set  N  =  X  o  N  and 

go  to  step  2.  ’ 

4.  If  there  exists  at  least  one  scheme  X  such  that  deg^{X)  -  0,  select  this  scheme  and  go  to  step  5.  Otherwise 

go  to  step  6.  o  , 

5.  Delete  from  A{L)  the  node  X  and  all  arcs  that  begin  in  X.  Then,  delete  X  from  L,  set  M  ^  MoX  and 

go  to  step  2.  ’ 

6.  Recalculate  A{L),  R{L),  and  R'{L).  Then,  return  the  scheme  M  o  Lo  N. 

Procedure  3. 

Inputs:  a  hammock  77  and  the  set  77(77). 

Outputs:  a  scheme  77'  and  the  set  77(77') . 
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1.  Construct  the  set  #  of  all  the  candidate  chains  for  removal  up  from  H  and  the  set !?,  of  all  the  candidate 
chains  for  removal  down  from  H.  Construct  the  graph  A{H)  and  set  F  =  G  =  e.  Then  go  to  step  2. 

2.  If  there  exists  at  least  one  chain  X  such  that  deg'^  {X)  =  0,  select  this  chain,  —  {X},  and 

go  to  step  3.  Otherwise,  go  to  step  6. 

3.  Delete  from  A{H)  all  arcs  that  begin  from  X.  Set  G  =  Comm{X)  oG.Jfa  dual  chain  for  X  exists,  then 
go  to  step  4.  Otherwise,  go  to  step  5. 

4.  J?  =  f?  U  {(T,X)}.  Go  to  step  2. 

5.  For  each  element  Xi  that  is  a  pseudoscheme,  delete  from  H  all  the  schemes  that  belong  to  set  d-dels{Xi). 
Then,  delete  all  elements  of  X  from  H.  Return  to  step  2. 

6.  If  there  exists  at  least  one  chain  X  £  ^  such  that  dep+(X)  =  0,  select  this  chain,  set  ^  \  {X},  and 

go  to  step  7.  Otherwise,  go  to  step  10. 

7.  Delete  from  A{H)  all  the  arcs  that  begin  from  X.  If  X  has  no  dual  chain  or  if  there  is  no  pair  of  the 
(T,X)  form  in  set  fi,  then  go  to  step  8.  Otherwise,  go  to  step  9. 

8.  For  each  element  Xi  that  is  a  pseudoscheme,  delete  from  H  all  the  schemes  that  belong  to  set  u-dels{Xi). 
Then,  delete  all  elements  of  X  from  H.Set  F  =  Fo  Camm{X)  and  return  to  step  6. 

9.  Let  (T,X)  G  From  T,  construct  a  pseudoscheme  for  which  par{T)  —  H,  f-dels{T)  =  f-dels{Xi), 
and  b-dels(T)  =  UiLi  b-dels{Xi)  (for  the  sake  of  convenience,  we  set  f-dels{Xi)  =  b-dels{Xi)  =  {XJ  if 
scheme  Xi  is  not  a  pseudoscheme).  Add  T  to  set  J7  and  delete  from  H  all  the  elements  of  X  and  X  that  are 
pseudoschemes.  Go  to  step  6. 

10.  Recalculate  A{i7),  R{H),  and  In  the  process,  we  should  take  into  account  only  those  deletions 

that  were  really  performed  (ordinary  schemes  are  not  deleted  when  pseudoschemes  are  constructed).  Then, 
return  the  scheme  H'  —  F  o  H  oG  and  the  set  n{.H')  —  11. 

Theorem.  The  scheme  that  is  obtained  from  the  input  scheme  as  a  result  of  applying  the  algorithm 
described  above  can  be  obtained  by  applying  transformations  of  removal  from  subloops  and  subhammocks. 

The  number  of  the  nodes  of  a  regular  scheme  S  will  be  called  its  size  and  denoted  by  |5'j.  The  depth  d(S)  of 
a  scheme  S  is  the  maximum  length  n  of  the  sequences  of  the  components  Ty,  . . .,  r„  such  that  Ti  is  a  proper 
subcomponent  of  Ci+i  for  alH  =  1,  . . .,  n  -  1.  If  there  are  no  such  sequences,  we  set  d{S)  =  1. 

Theorem.  The  algorithm  described  above  requires  the  time  0{d{S)\S\^time{m))  and  the  storage  0(15^  + 
space{m))  to  work  with  a  scheme  S.  Here  m  is  the  number  of  variables,  tiTne{m)  is  the  upper  bound  of  the  time 
required  for  one  operation  (n,  U,  or  \)  over  subsets  of  the  set  of  variables,  and  space{m)  is  the  upper  bound  of 
the  memory  needed  to  store  one  subset  of  the  set  of  variables. 

Theorem.  Let  S  be  an  irredundant  scheme  without  degenerate  subloops,  and  let  S'  be  a  scheme  ob¬ 
tained  from  S  by  applying  the  algorithm  described  above.  Let  S"  be  any  scheme  obtained  from  5  by  applying 
transformations  of  removal  from  subloops  and  subhammocks.  Then,  the  following  statements  are  true. 

1.  Let  I'  be  a  number  of  transformations  that  must  be  applied  to  obtain  S'  from  5,  and  let  I"  be  a  number 
of  transformations  that  must  be  applied  to  obtain  S"  from  S.  Then,  V  >1" . 

2.  \S'\  <  |5"j. 
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Abstract.  In  this  paper  we  present  the  functional  programming  language  OBJ-P.  OBJ-P  is  a  polymorphic 
extension  of  OBJ-3.  The  main  features  are  overloaded  function  symbols,  set  inclusion  subtyping,  and 
parametric  polymorphic  types. 

In  the  first  part  of  the  paper  we  give  an  introduction  to  the  core  language  and  the  semantic  base,  while  in 
the  second  part  the  module  system  is  presented  by  an  interesting  example  from  computer  algebra. 


1  Introduction 


The  functional  propamming  language  OBj-3  (e.g.  [GWM+93])  has  two  main  features:  overloading  of  function 
symbol  and  subtyping  in  the  sense  of  set  inclusion.  There  is  also  a  powerful  module  system  for  OBJ-3.  In  OBJ-3 
parameterized  types  are  missing.  There  is  sure  the  possibility  to  parameterize  whole  modules.  But  this  is  a  not 
good  solution,  because  if  one  type  within  a  module  has  a  parameter  the  whole  module  must  be  parameterized. 
We  extend  OBJ-3  by  parametric  polymorphic  types,  which  are  well-known  from  SML  [Mil97]  We  call  this 
extension  OBJ-P.  Furthermore,  we  change  a  little  the  module  system,  such  that  modules  can  be  parameterized 
y  mnction  a,nd  type  parameters.  This  means  that  OBJ-P  allows  both  of  parameterized  types  and  parameterized 
modules.  This  combination  leads  to  a  powerful  language  which  has  enormous  possibilities  to  reuse  code  and  to 
overload  function  symbols;  however,  function  evaluation  remains  unambiguous.  Our  overloading  feature  is  more 
expressive  than  overloading  in  Haskell  [PH+97]. 

These  features  (overloading  and  set  inclusion  subtyping)  are  very  interesting  in  computer  algebra,  as  in  math¬ 
ematics  we  deal  with  overloaded  function  names  and  with  set  hierarchies. 

The  semantic  base  of  OBJ-3  is  the  theory  of  order-sorted  algebras  (e.g.  [GM89]).  Therefore,  we  generalize  the 
theory  to  polymorphic  order-sorted  algebras.  For  our  theory  we  extend  the  theory  of  Smolka  [Smo88]. 


2  The  Functional  Programming  Language  OBJ-P 

2.1  Types,  Signatures,  and  Equations 

The  types  of  OBJ-P  propams  are  sorted  type  terms  Ts{TV)  over  a  finite  rank  alphabet  0  of  type  constructors 
and  a  set  or  type  variables  TV. 


Example  1.  The  following  OBJ-P  type  term  declaration  determines  the  types  of  the  integer  numbers 
vectors,  vectors,  and  matrices.  ’ 


non-scalar 


sorts  Int  'nsVector(a)  Vector(a)  Matrix(a)  . 
subsort  nsVector(a)  <  Vector(a)  . 
subsort  Vector (nsVector (a))  <  Matrix (a)  . 


The  basic  part  of  the  corresponding  infinite  type  term  ordering  is  given  by  the  following  Hasse  diagram; 


This  example  is  completed  later  to  the  OBJ— P  program  MATRIX. 

The  signatures  of  OBJ-P  programs  are  defined  as  polymorphic  order-sorted  signatures.  [Plu99] 
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Example  2.  The  following  OBJ-P  program  describes  the  signature  of  the  sum  function  over  integer  number, 
vectors,  and  matrices,  where  the  type  term  ordering  is  the  same  as  in  example  1. 

op  scalar  ;  a  ->  Vector (a)  . 

op  vec  :  a  Vector(a)  ->  nsVector(a)  . 

op  +  :  Int  Int  ->  Int  . 

op  +  :  Vector(Int)  Vector(Int)  ->  Vector  (Int) 
op  +  :  Matrixdnt)  Matrix(Int)  ->  Matrix(Int)  . 

[GM89]  gives  a  regularity  condition  for  order-sorted  signatures.  This  condition  guarantees  that  each  term  over 
a  regular  order-sorted  signature  has  a  least  type. 

We  generalized  this  regularity  condition  for  polymorphic  order-sorted  signatures  such  that  each  term  has  a  least 
principal  type.  [Plu99] 

The  semantics  of  OBJ-P  programs  is  defined  as  polymorphic  order-sorted  algebras  [Plu99],  which  is  declared  in 
OBJ-P  programs  by  recursive  equations  over  the  signature. 

Example  S.  The  OBJ-P  program  MATRIX  is  now  completed  by  the  equations. 

obj  MATRIX  is  , 

type  and  signature  declarations 

vars  si  s2  :  Int  . 

vars  vl  v2  :  Vector(Int)  . 

eq  + (scalar (s 1) ,  scalar (s2))  =  scalar (+ (si,  s2))  . 
eq  +(vec(sl,  vl) ,  vec(s2,  v2))  =  vec(+(sl,  s2) ,  +(vl,  v2))  . 
vars  vsl  vs2  :  nsVector(Int)  . 
vars  vvl  vv2  :  Vector (nsVector (Int))  . 
eq  +(scalar(vsl) ,  scalar(vs2))  =  scalar (+(vsl ,  vs2))  . 
eq  + (vec (vsl,  vvl),  vec(vs2,  vv2))  =  vec (+ (vsl,  vs2) ,  +(vvl,  vv2))  . 
endo 

2.2  The  Module  System  of  OBJ-P 

We  present  the  powerful  module  system  with  an  interesting  example,  which  shows  the  enormous  possibilities  of 
overloading  and  set  inclusion  subtyping  in  connection  -with  module  hierarchies. 

The  module  hierarchy  presented  in  this  example  describes  the  sum  of  polynomials  over  rings.  The  parameters  of 
this  module  are  the  ring  over  which  the  polynomials  are  defined  and  the  sum  over  the  ring  elements,  respectively. 
The  appendant  product  function  is  presented  in  [Plii99]. 

The  function  symbol  +  is  overloaded  with  the  sum  over  the  ring  elements,  the  monomials,  and  the  polynomials 
over  the  ring,  respectively.  There  is  a  predefined  module  Int,  which  exports  usual  functions  about  numbers. 

The  Recursive  Representation  of  Polynomials  In  the  SAC  LIB  [BCE+92]  computer  algebra  library,  poly¬ 
nomials  are  described  in  the  recursive  representation. 

The  OBJ-P  sorts  declaration  in  the  OBJ-P  module  Polynom  represents  recursive  polynomials  over  any  ring. 

module  Polynom  (nmPolynom(Ring) ,  nrMonom(Ring) , 

mono;  Ring  nzCard  ->  Monom(Ring) ,  ***  exports 

poly:  Monom(Ring)  Polynom  ->  nmPolynom(Ring) ) 

[sorts  Ring,  Polynom]  is  ♦**  parameters 

import  Int  . 

sorts  Monom(a)  nmPolynom(a)  . 

subsorts  Ring  Monom(Ring)  ninPolynom(Ring)  <  Polynom  . 
op  mono:  Ring  nzCard  ->  Monom(Ring)  . 
op  poly:  Monom(Ring)  Polynom  ->  nmPol3rnom(Ring)  . 
endm 

In  the  module  two  type  constructors  Monom  and  nmPolynom  are  declared.  The  type  Monom(Ring)  stands  for  the 
set  of  monomials  with  exponents  greater  than  0  and  nmPolynom(Ring)  stands  for  the  general  polynomials  (the 
non-monomial  polynomials).  Both  types  are  parameterized  by  the  module  parameter  Ring  which  stands  for  the 
type  of  the  ring  elements.  The  other  module  parameter  is  Polynom.  It  stands  for  the  type  of  the  union  of  all 
ring  elements  (Ring),  all  Monomials  (Monon(Ring)),  and  all  non-monomial  polynomials  (ninPolynom(Ring)).  The 
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exported  sorts  are  lunPolynom(Ring)  and  Momoii(Ring),  while  the  exported  constructors  (function  symbols)  are 
mono  and  poly. 

A  polynomial  in  this  representation  consists  of  a  list  of  monomials  with  the  list  constructor  poly.  In  this 
representation  the  names  of  the  variables  are  unknown. 

Now  we  give  an  example.  Let  us  consider  a  polynomial  in  two  variables: 

xl  +  {3x1  +  2a:i  +  l)ar|  +  (a;?  +  a:i  +  l)a;2  +  {xj  +  a:i  +  12). 

For  polynomials  in  two  variables  we  must  import  the  module  Polynom  twice: 

iii5>ort  Polynom  [Ring  =  Int,  Polynom  =  Polynoml]  . 
import  PolynomtRing  =  Polynoml,  Polynom  =  Polynom2] . 

where  Polynoml  (stands  for  Z[xi])  and  Polynom2  (stands  for  Z[xx][x2])  are  new  sorts,  which  are  instantiated  in 
the  imported  modules.  Then,  the  above  polynomial  is  represented  by: 

poly (mono (mono ( 1 ,  0) ,  3) , 

poly (mono (poly (mono (3,  3),  poly (mono (2.  1),  1)),  2), 

poly  (mono  (poly  (mono  (1,  2),  poly(mono(l.  1),  1)),  1), 
poly(mono(l,  2),  poly(mono(l,  1),  12))))) 


It  is  an  element  of  the  ring  Z[a;i][a:2].  Therefore,  the  type  is  Polynom2. 

If  we  have  a  closer  look  at  the  representation  (poly(mono(i,  2) ,  poiy(mono(l.  i) .  12)))  of  the  coefficient  (x?  + 
Xl  +  12)  (last  line)  we  notice  that  its  type  is  Polynoml  instead  of  Polynom2.  This  is  possible  as  the  type  Polynoml 
IS  a  subtype  of  Polynom2  induced  by  the  subsort  declaration  Ring  <  Polynom  in  module  Polynom  through  the 
second  import.  On  the  other  hand,  the  type  of  the  monomial  x|  (represented  by  mono  (mono  (1,  o) ,  3))  is 
Monom(Monom(Int) )  and  not  Monom(lnt)  as  Z[x2]  is  not  a  subset  of  Z[xi][x,2]. 

The  main  difference  to  the  usual  recursive  representation  of  polynomials  is  the  following:  A  polynomial  p  G 
i?[xij . . .  IS  usually  represented  in  R[xx] . . .  [xn]  as  p  •  x^  and  not  as  p  like  in  our  representation.  This  is 

only  possible,  because  OBJ-P  allows  set  inclusion  subtyping  and  multiplied  importation  of  one  module  with 
different  parameter  instantiations. 

Sum  of  Polynomials 


module  PolynomSUM  (+:  Polynom  Polynom  ->  Polynom)  ♦♦♦  exports 

[sorts  Ring  Polynom,  op  +:  Ring  Ring  ->  Ring]  is 
import  Int  .  paxameters 

import  Polynom[Ring  =  Ring,  Polynom  =  Polynom].  ♦♦♦  import  where 

♦♦♦  the  parameters 

op  +;  Polynom  Polynom  ->  Polynom  .  o.**  are  instatiated 


vars  coel  coe2  re  :  Ring  . 
vars  expl  exp2  :  nzCard  . 
vars  pi  p2  :  Polynom  . 
var  m  :  Monom(Ring)  . 

eq  +(mono(coel,  expl),  re)  =  poly(mono(coel,  expl),  re)  . 
eq  +(poly(m,  pi),  re)  =  poly(m,  +(pl,  re))  . 
eq  +(mono(coel,  expl),  mono(coe2,  exp2))  =  ... 
eq  + (poly (mono (coel,  expl),  pi),  mono(coe2,  exp2))  = 

if  (expl  >  exp2)  then  poly (mono (coel,  expl),  +(pl,  mono(coe2,  exp2))) 
else  - 

if  (exp2  >  expl)  then  poly (mono (coe2,  exp2) ,  poly (mono (coel,  expl),  pi)) 
else  poly (mono (+ (coel,  coe2) ,  expl),  pi)  fi  fi  . 

eq  + (poly (mono (coel ,  expl),  pi),  poly (mono (coe2,  exp2) ,  p2))  = 
eq  +(pl,  p2)  =  +(p2,  pi)  . 
endm 


In  the  module  PolynomSUM  there  is  a  function  call  named  by  the  overloaded  function  symbol  s-  (underlined) 

^  recursive  call  (depended  on  the  argument  type)  or  the  call  of  the  module 
parameter  +  function.  This  is  an  example  for  the  overloading  feature  in  OBJ-P. 
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The  module  PolynomSUM  is  a  parameterized  module  similar  to  the  module  Polynom.  Now  we  present  different 
possibilities  to  import  these  two  modules. 

Polynomials  over  the  Integer  Numbers 

module  Int2PolynomSUM  is 
sorts  Polynoml  Polynoin2  , 
import  Int  . 

import  PolynomSUM  [Ring  =  Int,  Polynom  =  Polynoml, 

+  =  +:  Int  Int  ->  Int]  . 

import  PolynomSUM  [Ring  =  Polynoml,  Polynom  =  Polynom2, 

+  =  +:  Polynoml  Polynoml  ->  Polynoml]  . 

op  Main:  Polynom2  Polynom2  ->  Polynom2  . 
vars  X  y  :  Polynom2  . 
eq  MainCx,  y)  =  +(x,  y)  . 
endm 

The  module  PolynomSUM  is  imported  twice.  While  in  the  first  import  the  parameters  of  PolynomSUM  are  instantiated 
by  Int,  Polynoml,  and  +:  Int  Int  ->  Int,  in  the  second  import  the  parameters  Ring  and  +:  Ring  Ring  ->  Ring 
are  instantiated  by  the  already  imported  types  Polynoml  and  +:  Polynoml  Polynoml  ->  Polynoml  and  Polynom  is 
instantiated  by  the  additionally  declared  type  polynom2.  Finally,  the  function  Main  define  the  polynomial  sum 
over  the  ring  Z[a:i]  [3:2]  • 

We  notice  that  the  type  Polynoml  is  the  union  of  Int,  Monom(Int) ,  and  nmPolynom(Int)  while  Polynom2  is  the  union 
of  Polynoml,  Monom (Polynoml),  and  nmPolynom(Polynoml).  Prom  this  follows  that  the  Main  function  is  enormously 
overloaded.  Main  is  applicable  to  integer  numbers,  to  polynomials  in  the  variable  Xi  as  well  as  to  polynomials  in 
the  variables  xi  and  X2,  and  to  the  mixture  of  all  these  types.  This  is  a  very  natural  way  to  overload  the  sum 
function.  In  languages  like  Haskell  [PH+97]  this  is  impossible,  as  we  have  shown  in  [Plu99]. 

Polynomials  over  Z/n  The  ring  over  which  the  polynomials  are  defined  is  now  Z/n.  We  assume  that  there  is 
module  Zmodn,  which  is  parameterized  by  n  and  where  the  sum  function  of  Z/n  is  exported. 

module  Zmod43PolynomSUM  is 
import  Int  . 

import  Zmodn  [n  =  4]  as  Zmod4  .  the  identifiers  id  are  used 

**♦  qualified  as  Zmod4.id 
sorts  Polynoml,  Polynom2,  PolynomS  . 

import  PolynomSUM  [Ring  =  Card,  Polynom  =  Polynoml,  +  =  Zmod4.+:  ...]  . 

import  PolynomSUM  [Ring  =  Polynoml,  Polynom  =  Polynom2,  +  =  +:  ...]  . 

import  PolynomSUM  [Ring  =  Polynom2,  Polynom  =  PolynomS,  +  =  +:  . . .]  . 

op  Main:  PolynomS  PolynomS  ->  PolynomS  . 
vars  X  y  : -PolynomS  . 
eq  Main(x,  y)  =  +(x,  y) 
endm 


The  Main  function  defines  the  sum  of  polynomials  over  ZIA[x{\\x2][x‘i]. 

This  example  shows  the  possibilities  for  reuse  code  in  OBJ-P.  It  is  possible  to  give  a  new  sum  function  (in  this 
example  from  module  Zmodn)  and  assign  them  to  the  function  parameter  +  in  the  module  PolynomSUM,  while  the 
code  of  PolynomSUM  is  unchanged. 

Summary  The  subtypiiig  feature  of  OBJ-P  allows  to  represent  polynomials  p  e  J?[a:i] . . .  [3:^]  in  the  supertype 
ii[3:i] . . .  [3;„],  (m  <  n)  identical  as  in  R[xi] . . .  [xot].  This  is  not  possible  in  other  programming  languages. 
Furthermore,  the  subtyping  feature  enables  the  sum  function  to  have  only  two  arguments,  instead  of  three  (the 
number  of  variables)  as  would  usually  be  expected  (cf.  SACLIB  [BCE+92]). 

Additionally,  because  of  the  overloading  feature  of  OBJ-P,  there  is  the  same  function  symbol  for  the  sum 
function  over  ring  elements,  monomials,  and  polynomials,  although  these  sets  of  elements  are  represented  by 
different  types. 
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3  Conclusion  and  Further  Work  ~ 

We  have  presented  the  programming  language  OBJ-P,  which  has  the  special  features  of  overloaded  function 
symbols,  set  inclusion  subtypmg,  and  parametric  polymorphic  types.  OBJ-P  is  very  suitable  for  computer  alge¬ 
bra  as  in  the  mathematics  we  deal  often  with  overloaded  function  names  and  set  hierarchies.  The  combination 

AdchtionaltT  7pr 001™  1.  possibilities  to  overload  function  symbols  than  in  Haskell. 

Additionally,  in  lPlu99]  we  have  defined  a  type  inference  system  and  a  corresponding  type  reconstruction 

^gonthm,  which  allows  us  to  omit  the  declarations  of  the  function  symbols  and  the  variable  declarations  in 
'JDj— p  programs. 
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Abstract.  We  report  results  of  a  joint  project  with  Prance  Telecom  on  the  modelling  of  telephone  services 
(features)  using  formal  methodologies  such  as  00  ACT  ONE,  B  and  TLA"*".  We  show  how  we  formalise  the 
feature  interaction  problem  in  a  multi-view  model,  and  we  examine  issues  such  as  animation,  validation, 
proof  and  verification. 


1  Introduction 

In  this  section  we  briefly  introduce  the  need  for  formal  methods  in  software  engineering,  the  use  of  formal 
methods  to  help  resolve  the  feature  interaction  problem,  and  the  particular  formal  methods  we  adopt  in  our 
mixed-semantic  model. 

1.1  Formality 

Many  software  engineers  do  not  acknowledge  the  value  of  formality.  In  1993,  a  major  study  [13]  concluded 
by  stating:  "...  formal  methods,  while  still  immature  in  certain  important  respects,  are  beginning  to  be  used 
seriously  and  successfully  by  industry  to  design  and  develop  computer  systems  ...”  We  believe  that  formal 
methods  are,  five  years  later,  just  about  ready  for  transfer  to  the  industrial  development  of  telephone  features. 
Like  all  forms  of  engineering,  one  must  always  compromise  between  quality  and  cost.  In  telephone  systems,  it 
appears  that  the  cost  of  resolving  interactions  between  features  at  the  implementation  stage  is  now  (or  will 
soon  be)  greater  than  the  cost  of  developing  formal  features  requirements  models  and  eliminating  many  of  the 
potential  interactions  before  implementation  begins.  Formal  methods  in  this  domain  should  be  regarded  as  an 
investment  for  the  future. 

There  are  a  wide  and  varied  range  of  definitions  of  formal  method  which  can  be  found  in  the  majority  of  texts 
concerned  with  mathematical  rigour  in  computer  science.  The  most  common  methods  used  for  telephone  feature 
specification  are  reviewed  in  [42].  For  the  purposes  of  this  paper  we  propose  the  following  definition:  A  formal 
method  is  any  technique  concerned  with  the  construction  and/or  analysis  of  mathematical  models  which  aid  the 
development  of  computer  systems.  Formal  methods  are  fundamentally  concerned  with  correctness:  the  property 
that  an  abstract  model  fulfils  a  set  of  well  defined  requirements.  In  this  paper,  we  are  concerned  with  the 
construction  of  such  requirements  models. 

A  formal  model  of  requirements  is  unambiguous  —  there  is  only  one  correct  way  to  interpret  the  behaviour 
being  defined.  Although  the  model  must  still  be  mapped  onto  the  real  world  (i.e.  validated  by  the  customer), 
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this  mapping  is  in  essence  more  rigorous  than  in  informal  approaches.  Building  a  formal  model  requires  a  better 
understanding  of  the  problem  domain  and  a  better  understanding  of  how  the  problem  domain  is  viewed  by  the 
customer. 

A  major  problem  when  using  formal  methods  in  software  engineering  is  that  much  of  the  recent  research  places 
emphasis  on  analysis  rather  than  synthesis.  The  means  of  constructing  complex  formal  models  is  often  overlooked 
in  favour  of  techniques  for  analysing  models. 

Re-usable  analysis  techniques  will  automatically  arise  out  of  re-usable  composition  mechanisms.  Formal  method 
engineers  need  to  learn  techniques  for  building  very  large,  complex  systems.  Such  techniques  have  been  followed, 
with  various  degrees  of  success,  by  programmers.  In  particular,  object  oriented  programmers  have  evolved 
techniques  which  have  been  successfully  transferred  to  the  analysis  and  design  phases  of  software  engineering. 
Where  better  then  to  look  for  aid  in  the  construction  of  large  formal  models? 


1.2  Feature  Interactions 

A  feature  interaction  is  a  situation  in  which  system  behaviour  is  specified  as  a  composition  of  some  set  of  features: 
each  individual  feature  can  meet  its  requirements  in  isolation  but  all  features  cannot  meet  their  requirements 
when  composed. 

The  problem  of  feature  interaction  is  a  major  topic  in  telecommunications  where  formal  methods  have  been 
usefully  applied.  There  is  no  single  technique  which  addresses  all  the  aspects  of  the  problem,  but  the  most 
commonly  used  approaches  that  have  been  used  to  tackle  the  problem,  at  the  requirements  stage,  are:  SDL  [29, 
30],  LOTOS  [18, 7, 17],  state  machine  and  rule  based  representation  [19],  and  temporal  logic[4,3, 11],  . 

1.3  Our  formal  models 

In  our  formal  approach,  interactions  occur  only  when  requirements  of  multiple  features  are  contradictory.  The 
complexity  of  understanding  the  problem  is  thus  contained  within  a  definition  of  contradiction  in  our  semantic 
framework.  We  have  argued  that  in  most  of  the  feature  interaction  examples  found  in  published  texts,  there 
p  no  generally  accepted  standard  formal  definition  of  feature  interaction[25,43, 6, 9, 15].  In  fact,  most  of  the 
mteractions  which  we  studied  correspond  to  incomplete  and  informal  requirements  models.  In  other  words 
if  the  features  were  modelled  better  then  we  would  be  able  to  better  understand  what  is  and  what  isn’t  ai^ 
interaction. 

LOTOS  (Language  Of  Temporal  Ordering  Specifications),  see  [40,28],  is  a  wide  spectrum  language,  which  is 
suitable  for  specifying  systems  at  various  levels  of  abstraction.  Consequently,  it  can  be  used  at  both  ends  of 
the  software  development  spectrum.  Its  natural  division  into  ADT  part  (based  on  ACT  ONE  [16])  and  process 
algebra  part  (similar  to  CSP  [26]  and  CCS  [37])  is  advantageous  since  it  provides  the  flexibility  of  two  different 
expressing  behaviour,  whilst  managing  to  integrate  them  in  a  relatively  coherent  fashion. 
LOTOS  provides  an  elegant  way  to  specify  services  and  to  detect  interaction  among  services;  it  allows  the  user 
J  ^  compositional  manner  and  it  provides  a  set  of  tools  such  as  LITE  from  the  project 

UiUbPHERE  ,  to  assist  in  service  engineering.  Questions  regarding  fairness  cannot  be  easily  expressed  or 
so  ved  in  LOTOS:  modeling  fairness  requires  us  to  state  properties  on  traces,  or  a  scheduling  policy,  and  LOTOS 
has  not  yet  integrated  fairness  constraints. 

lotos  in  our  project  and  compared  the  expressivity  of  different  languages  such  as  B,  TLA+ 
and  00  ACT  ONE  LOTOS  [23];  our  conclusions  are  clear  on  the  expressivity  of  TLA,  and  on  the  availability 
of  practical  development  environments  for  B  and  LOTOS.  The  style  of  specification  plays  a  very  important 
role  and  the  approach  of  Gammelgaard  [19]  is  automaton-oriented,  their  approach  uses  a  specification  language 
based  on  transition  systems  as  predicates.  The  weakness  of  their  solution  relies  on  the  partial  view  of  details 
but  a  sound  and  semantically  corhplete  reasoning  system  is  required.  The  solution  using  TLA  [31,24]  borrows 
the  initial  idea  from  their  mmdel,  but  TLA  has  the  advantage  of  a  very  carefully  equipped  proof  system.  Finally 
as  the  temporal  framework  can  be  very  expressive,  we  need  a  computer-aided  proof  environment  and  more 
generally  applicable  software  environments  based  on  these  formalisms. 

Blow  et  Al.  [3]  and  Middelburg  [36]  investigate  the  use  of  temporal  logic  for  specifying  services;  Blom  uses  a 
temporal  logic  integrating  the  reactive  and  the  frame  parts  for  services.  Middelburg  introduces  a  temporal  logic 
ot  branching  time  and  restrict  its  expressivity  to  obtain  a  TLA-like  logic. 

In  fact,  the  integration  of  very  different  formalisms  such  as  TLA,  B  and  LOTOS  is  a  way  to  improve  service 
engineering.  B  is  simple  and  a  tool  helps  the  user  in  developing  specifications:  we  do  not  claim  that  B  will  solve 
^  (see  littp;//wwwtios. cs.utwente.nl/lotos/) 
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the  entire  problem  but  it  is  very  helpful  in  the  building  of  requirements  models  for  telecommunication  services. 
As  we  emphasize  B  as  a  tool  for  developing  services  specifications  using  a  theorem  prover,  another  crucial 
element  of  B  is  its  animator.  Several  problems  are  detected  by  animation  which  do  not  need  to  be  resolved  by 
the  prover.  We  have  explored  B  as  a  tool  for  service  engineering,  although  it  was  not  one  of  the  original  goals  of 
the  language.  Another  point  is  that  B  and  TLA  are  very  close,  at  least  for  the  action  part;  we  have  studied  the 
integration  of  B  and  TLA  [35]  to  re-use  the  B  tools  for  TLA  and  to  extend  the  scope  of  B  by  temporal  features. 
Our  paper  is  organized  as  follows.  Section  2  describes  our  mixed  model  involving  different  aspects  of  the  formal 
development.  Section  3  introduces  service  requirements.  Section  4  gives  details  on  the  way  we  model  services  in 
TLA+;  we  explain  how  our  mixed  views  can  be  checked  to  be  coherent.  Section  5  concludes  our  paper. 

2  A  Mixed  Semantic  Model 

We  have  shown  the  need  for  a  mixed  semantic  model  when  specifying  telephone  feature  requirements  [22].  Such 
a  model  is  used  to  provide  three  different  client  views: 

-  An  object  oriented  view  which  provides  the  operational  semantics  used'during  animation  for  validation,  and 
the  structuring  mechanisms  which  are  fundamental  to  our  approach.  This  view  is  formalised  using  an  object 
oriented  style  of  specification  in  LOTOS  [20]. 

-  An  invariant  view  which  allows  the  client  to  describe  abstract  properties  of  a  system  (or  component) 
which  must  always  be  true.  This  view  is  formalised  using  B  and  leads  to  the  automatic  detection  of  many 
interactions  [33,34]. 

-  A  fairness  view  which  allows  the  client  to  describe  properties  of  the  system  which  must  eventually  be  true 
even  though  they  have  no  direct  control  over  them.  A  temporal  logic  provides  an  ideal  means  of  specifying 
and  verifying  such  requirements  [23]. 

2.1  Objects  and  Classes 

Labelled  state  transition  systems  are  often  used  to  provide  executable  models  during  the  analysis  and  require¬ 
ments  stages  of  software  development  [12,14].  In  particular,  such  niodels  play  a  role  in  many  of  the  object 
oriented  analysis  and  design  methods  [5,10].  However,  a  major  problem  with  state  models  is  that  it  can  be 
difficult  to  provide  a  good  decomposition  of  large,  complex  systems  when  the  underlying  state  and  state  tran¬ 
sitions  are  not  fully  understood.  The  object  oriented  paradigm  provides  a  natural  solution  to  this  problem.  By 
equating  the  notion  of  class  with  the  state  transition  system  model,  and  allowing  the  state  of  one  class  to  be 
defined  as  a  composition  of  states  of  other  classes,  we  provide  a  means  of  specifying  state  transition  models  in  a 
constructive  fashion.  Further,  such  an  approach  provides  a  more  constructive  means  of  testing  actual  behaviour 
with  required  behaviour. 

This  state  based  view  forms  the  basis  on  which  we  build  our  feature  animations  and  permits  behaviour  validation 
in  a  compositional  manner.  However,  such  operational  models  are  not  good  for  formal  reasoning  about  feature 
requirements  [44]:  for  this  we  need  to  consider  specification  of  state  invariants  and  fairness  properties. 


2.2  Invariants 

Invariants  are  used  to  specify  properties  of  a  system  which  must  always  be  true  for  reachable  states.  Within  the 
object  oriented  framework  we  have  three  kinds  of  invariant: 

-  Typing:  By  stating  that  all  objects  are  defined  to  be  members  of  some  class  we  are  in  fact  specifying  an 
invariant.  These  invariants  are  verified  automatically  by  our  object  oriented  tools. 

-  Service  requests:  Typing  also  permits  us  to  state  that  objects  in  our  system  will  only  ever  be  asked  to 
perform  services  that  are  part  of  their  interfaces.  These  invariants  are  also  verified  automatically  by  the 
object  oriented  tools. 

-  State  Component  Dependencies:  In  a  structured  class  we  may  wish  to  specify  some  property  that 
depends  on  the  state  of  two  or  more  of  the  components,  and  which  is  invariant.  This  cannot  be  statically 
verified  using  the  object  oriented  tools,  but  it  can  be  treated  through  a  dynamic  analysis  (model  check). 
Unfortunately,  such  a  model  check  cannot  be  guaranteed  when  we  have  a  large  (possibly  infinite)  number 
of  states  in  our  systems.  For  this  reason  we  need  to  utilise  a  less  operational  framework.  By  translating  our 
state  invariant  requirements  into  B,  we  have  been  able  to  statically  verify  our  state  component  invariants. 
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2.3  Nondeterminism  and  fairness 

TLA  is  a  temporal  logic  introduced  by  Lamport  [31]  and  based  on  the  action-as-relation  principle.  A  system  is 
considered  as  a  set  of  actions,  namely  a  logical  disjunction  of  predicates  relating  values  of  variables  before  the 
activation  of  an  action  and  values  of  variables  after  the  activation  of  an  action;  a  system  is  modeled  as  a  set 
of  traces  over  a  set  of  states.  The  specifier  may  decide  to  ignore  traces  that  do  not  satisfy  a  scheduling  policy 
such  as  strong  or  weak  fairness,  and  temporal  operators  such  as  □  (Always)  or  O  (Eventually)  are  combined  to  * 
express  these  assumptions  over  the  set  of  traces.  Such  fairness  is  important  in  feature  specification  and  cannot 
be  easily  expressed  using  our  state  based  semantics.  The  key  is  the  need  for  nondeterminism  in  our  requirements 
models. 

Without  a  temporal  logic,  nondeterminism  in  the  features  can  be  specified  only  at  one  level  of  abstraction:  namely 
that  of  an  internal  choice  of  events.  This  can  lead  to  many  problems  in  development.  For  example,  consider  the 
specification  of  a  shared  database.  This  database  must  handle  multiple,  parallel  requests  from  clients.  The  order 
m  which  these  requests  are  processed  is  required  to  be  nondeterministic.  This  is  easily  specified  in  our  object 
model.  However,  the  requirements  are  now  refined  to  state  that  every  request  must  be  eventually  served  (this  is 
a  fairness  requirement  which  we  cannot  directly  express  in  our  semantic  framework).  The  only  way  this  can  be 
done  IS  to  overspecify  the  requirement  by  defining  how  this  fairness  is  to  be  achieved  (for  example,  by  explicitly 
queueing  the  requests).  This  is  bad  because  we  are  enforcing  implementation  decisions  at  the  requirements  level 
With  TLA  we  can  express  fairness  requirements  without  having  to  say  how  these  requirements  are  to  be  met. 


2.4  Composition  Mechanisms 

Composition  is  primarily  a  question  of  re-use:  given  two  already  specified  components,  how  can  we  create  a  new 
component  from  those  given?  A  composition  mechanism  defines  a  creation  mechanism  which  is  reusable  (i.e 
can  be  applied  to  different  sets  of  components).  Clearly,  we  have  to  be  more  precise  as  to  the  meaning  of  a 
component.  iFrom  the  customer’s  point  of  view,  and  hence  at  the  requirements  level  of  abstraction,  a  component 
must  be  some  piece  of  behaviour  which  can  be  validated  independently.  In  other  words,  a  component  must  be 
able  to  be  seen  as  a  model  of  behaviour  in  its  own  right.  We  give  an  overview  of  the  composition  techniques  from 
SJture^'^’'  points  and  argue  that  a  user  oriented  view  would  be  best  during  requirements 

(1)  Object  oriented  composition  in  LOTOS: 

LOTOS  [8]  is  made  up  from  an  abstract  data  type  part  [32],  and  a  process  algebra  part  [26].  Clearly  there  are 
ways  of  composing  behaviours  in  each  of  these  models.  However,  the  object  oriented  composition  is  at  a  higher 

level  of  abstraction.  We  do  not  compose  with  language  operators;  rather  we  compose  using  object  oriented 
concsptis. 

(2)  Invariant  composition  (in  B); 

B  [1]  is  a  model-oriented  method  providing  a  complete  development  process  from  abstract  specification  towards 
implementations  through  step-by-step  refinement  of  abstract  machines.  An  abstract  machine  describes  data 
operations  and  invariant  preserved  by  every  operation.  Abstract  machines  are  composed  by  conjunction  of  its 
invariants  and  combination  of  operations.  The  resulting  abstract  machine  may  either  preserve  the  resulting 
mvanant,  or  invalidate  it.  The  violation  of  the  invariant  is  interpreted  as  an  interaction  [34]  and  is  in  fact  an 
mterference  between  operations:  it  is  a  way  to  detect  interaction  among  services  specified  as  abstract  machines. 
Ihe  main  advantage  of  B  is  that  it  is  supported  by  a  powerful  sofware  environment,  namely  the  Atelier  B  [39]. 
The  B  method  [1]  is  itself  a  conceptual  tool  for  specifying,  refining  and  developing  systems  in  a  mathematical 
and  rigorous,  but  simple  way. 

(3)  Fairness  composition  (in  TLA): 

The  composiHon  of  fmrness  assumptions  in  TLA  is  done  at  a  high  level  of  abstraction  and  is  preserved  through 
the  composition  process.  A  model  for  a  TLA  formula  is  an  infinite  trace  of  states,  and  a  TLA  specification  is 
made  up  of  three  parts: 

-  the  initial  conditions,  Init, 

-  the  relation  over  variables,  Next(x,x'),  and 

-  the  fairness  constraints,  WFx(A)  A  f\  SFx(A)  (we  require  that  A  Next(x,x'),  for  all  A  in 

AeWFA  AeSFA 

WFA  or  SFA  to  ensure  the  machine-closure  property). 

Fairness  constraints  remove  models  or  traces  that  do  not  satisfy  them.  A  service  is  characterized  by  a  set  of 
flexible  variables,  initial  conditions,  a  next  relation  over  variables  and  fairness  contraints.  When  combining 
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two  services,  we  increase  the  restrictions  over  traces  but  we  extend  the  models  by  adding  new  variables.  TLA 
provides  an  abstract  way  to  state  fairness  assumptions  but  in  our  approach  this  unfriendly  syntax  is  hidden 
from  the  customer.  We  encapsulate  fairness  within  each  object  as  a  means  of  resolving  nondeterminism  due  to 
internal  state  transitions.  This  is  a  simple  yet  powerful  way  for  the  fairness  to  be  structured  and  re-used  within 
our  requirements  models. 

(4)  Feature  composition  (user  conceptualisation): 

In  an  ideal  world,  feature  composition  would  be  done  using  concepts  within  the  clients’  conceptual  model  of 
their  requirements.  Clients  cannot  be  expected  to  express  themselves  using  formal  language  operators.  This 
does  not  mean  that  they  cannot  express  themselves  formally.  It  is  the  role  of  the  analyst  to  map  the  clients’ 
composition  concepts  onto  composition  methods  in  the  formal  model.  For  now,  we  are  forced  to  communicate 
through  the  object  oriented  models  (which  could  be  argued  to  be  client  friendly).  In  the  future  we  hope  to 
develop  a  modeling  language  based  on  client  concepts  rather  than  modeling  language  concepts. 

3  Requirements  for  features 

3.1  Requirements  Modeling:  Customer  Orientation 

Requirements  capture  is  the  first  step  in  the  process  of  meeting  customer  needs.  Building  and  analysing  a  model 
of  customer  needs,  with  the  intention  of  passing  the  result  of  such  a  process  to  system  designers,  is  the  least 
well  understood  aspect  of  software  engineering.  The  process  is  required  to  fulfil  two  very  different  needs;  the 
customer  must  be  convinced  that  requirements  are  completely  understood  and  recorded,  and  the  designer  must 
be  able  to  use  the  requirements  to  produce  a  structure  around  which  an  implementation  can  be  developed  and 
tested.  In  this  paper,  we  concentrate  on  the  customers’  point  of  view,  whilst  noting  that  the  object  oriented 
approach  does  lend  itself  to  meeting  the  designers’  needs  [21].  We  advocate  such  a  customer  oriented  approach 
since  it  is  generally  agreed  that  customer  communication  is  the  most  important  aspect  of  analysis  [27,38,41]. 
The  fundamental  principle  of  requirements  capture  is  the  improvement  of  mutual  understanding  between  cus¬ 
tomer  and  analyst,  and  the  recording  and  validation  of  such  an  understanding  in  a  structured  model.  The 
successful  synthesis  of  a  requirements  model  is  dependent  on  being  able  to  construct  a  system  as  the  customer 
views  the  problem.  [2,25]  illustrate  this  point  with  respect  to  feature  models. 


3.2  Feature  Interaction:  What’s  new? 

We  concentrate  on  the  domain  of  telephone  features,  where  the  problem  has  been  acknowledged  for  many 
yeafs![6,9].  Figure  1  illustrates  the  problem  within  the  formal  framework  which  we  adopt  throughout  this 
paper.  We  note  that  the  means  by  which  features  are  composed  is  not  specified. 

Features  are  observable  behaviour  and  are  therefore  a  requirements  specification  problem  [45].  Many  feature 
interaction  problems  can  be  resolved  through  communication  with  the  customer  during  requirements  capture. 
Given  a  feature  requirements  specification  which  is  not  contradictory,  interaction  problems  during  the  design 
and  implementation  will  arise  only  through  errors  in  the  refinement  process.  Certainly  the  feature  interaction 
problem  is  more  prone  to  the  introduction  of  such  errors  because  of  the  highly  concurrent  and  distributed 
nature  of  the  underlying  implementation  domain,  but  this  is  for  consideration  after  each  individual  feature’s 
requirements  have  been  modelled  and  validated.  We  have  extended  the  work  given  in  [25],  where  the  composition 
of  features  was  done  in  an  ad-hoc  fashion,  by  identifying  and  formalising  re-usable  composition  mechanisms. 
The  configuration  of  multiple  features  will  be  shown  to  depend  on  the  way  in  which  individual  features  are 
composed  with  POTS  (plain  old  telephone  service). 

Features  are  requirements  modules  and  the  units  of  incrementation  as  systems  evolve.  A  telecom  system  is  a 
set  of  features.  Having  features  as  the  incremental  units  of  development  is  the  source  of  our  complexity.  An 
understanding  of  feature  composition  helps  us  manage  the  four  main  sources  of  this  complexity  — 

(1)  State  explosion: 

Potential  feature  interactions  increase  exponentially  with  the  number  of  features  in  the  system  and  traditional 
model  checking  techniques  cannot  cope  with  the  complexity.  The  fundamental  problem  is  that  analysis  can¬ 
not  be  done  compositionaJly.  We  argue  that  compositional  (re-usable)  analysis  depends  on  having  a  formal 
understanding  of  the  composition  mechanisms.  This  is  the  main  goat  of  this  work. 

(2)  Chaotic  Information  Structure  In  Sequential  Development  Strategies: 

The  arbitrary  sequential  ordering  of  feature  development  is  what  drives  the  internal  structure  of  the  resulting 
system.  As  each  new  feature  is  added  the  feature  must  potentially  include  details  of  how  it  is  to  be  configured 
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Feature  I 


Fig.  1.  Feature  Interaction;  A  formalisation 


with  all  the  features  already  m  the  system.  Consequently,  to  understand  the  behaviour  of  one  feature  it  is 

LTdV  \  of  the  features  in  the  system.  All  conceptual  integrity  is  lost ’since 

t  e  distribution  of  knowledge  IS  potentially  chaotic.  At  the  moment  this  is  certainly  true.  Howver,  we  believe 

a  re-u’sable  set  of 

(3)  Implicit  Assumption  Problem: 

f  "'W*  i”*  "O  longer  true  when  later  features  arc  conceived 

&nsequently,  teatuns  may  rdy  on  contradictory  (implicit)  assumptions.  This  is  a  great  source  of  interactions 

of  cor^fi^mt^meltirs  <“•»«)  %  forcing  them  to  use  a  certain  set 

(4)  Independent  Development: 

Jaditional  approaches  require  a  new  feature  developer  to  consider  how  the  feature  operates  with  all  others 
already  on  the  system.  Consequently,  we  cannot  concurrently  develop  new  features:  since  how  the  new  features 

amrdifiM  Considered  by  either  of  the  two  independent  feature  developers.  This  problem  is 

amplified  if  feature  developers  can  configure  features  in  any  way  that  they  wish. 


Feature  Interaction:  An  incremental  development 


view 


In  figure  2,  we  take  POTS  as  one  requirement  model.  We  note  that  to  extend  this  base  requirement  with  a 
new  feature  we  must  define  a  means  of  composing  POTS  with  this  feature,  or,  as  illustrated  in  the  diagram 
use  a  previously  defined  mechanism.  Unfortunately,  for  two  different  features  there  is  no  Sarantee  thS  we 
can  use  the  same  composition  mechanism.  Furthermore,  for  each  composition  we  may  require  an  additional 

toluuriSfeqSernr^  "  couflgured  i„  order  to  gurantee 

Given  such  a  composition  technique  we  must  now  address  the  problem  of  integrating  Featurel  and  Feature2 

two  feaTmeV^d1o7?hnwo“co  ■  T  “fraction  occurs  if  the  invariants  introduced  by  the 

two  teatures  and/or  the  two  composition  mechanisms  are  contradictory.  Properties  are  required  to  be  nreservpd 

TLaT'*"™"'  ^  <“‘"6 
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Satisfies  P  )  (  Satisfies  F2 


RE-USE 


Satisfies  P  and  FI  iff 
InvUPOTS, Feature!) 

where,  Invl  is  an  invariant 
of  the  composed  ^em 
which  is  enforced  by  the 
composition  mechanism 
compl 


Satisfies  P  and  F2  iff 
Inv2(POTS.Feature2) 


where,  lnv2  is  an  invariant 
of  the  composed  system 
which  is  enforced  by  th 
composition  mechanism 
comp2 


Fig.  2.  Incrementing  POTS 


Satisfies? and  PI  iff 
Inv!(POTS,Featurel) 


where,  Invl  is  an  invariant 
of  the  compiled  system 
which  is  enforced  by  the 
composition  mechanism 
compl 


Satisfies  P  and  F2  iff 
Inv2(POTS,Feature2) 


where,  lnv2  is  an  invariant 
office  cwnposed  system 
which  is  enforc«J  by  th 
composition  mechanism 
comp2 


Satisfies  P  and  FI  and  F2  iff 
Inv  1  (POTS,Feahire  1 ) 
and 

Inv2(POTS,  Feature2) 
and 

P  and  FI  andF2 


-  Composel (compl (POTS, featurel) ,  feature2),  where  we  compose  the  feature2  with  the  component 
which  results  from  a  composition  between  POTS  and  the  featurel. 

-  Compose2(comp2(P0TS,feature2) ,  featurel),  where  we  compose  the  featurel  with  the  component 
which  results  from  a  composition  between  POTS  and  the  feature2. 

-  Composes  (POTS ,  compS  (featurel ,  f  eature2) ) ,  where  we  first  compose  the  two  features  and  then  compose 
this  new  component  with  POTS. 

-  Compose4(P0TS,  featurel,  feature2),  where  we  define  a  new  composition  mechanism  which  acts  on  all 
three  components. 

The  feature  composition  problem  is  certainly  difficult  (even  when  there  are  only  2  features);  now  we  argue  that 
having  formal  requirements  models  makes  it  manageable,  but  we  need  to  develop  a  methodology  for  composing 
features 

4.1  Modelling  services 

A  service  is  an  extension  of  POTS,  POTS  is  the  basic  service,  providing  functionality  to  the  customer  for 
interacting  with  the  switch  and  the  billing  system.  The  modeling  of  services  is  based  on  the  view  of  services 
as  processes  altering  a  set  of  calls.  The  current  state  of  a  service  is  characterized  by  an  invariant  over  calls.  A 
call  is  a  structure  that  manages  and  describes  the  current  parameters  as  the  caller,  the  callee,  the  call  state, 
the  paying  party  . . .  However,  a  call  may  be  extended  into  another  call  by  operations  over  calls  such  as  fusion, 
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Fig.  4.  View  of  services  through  calls 


completion  etc.  It  means  that  calls  are  central  concepts  in  our  modelling  but  this  makes  the  modelling  more 
flexible.  More  generally,  a  call  is  a  structure  recording  the  current  participants,  the  connection,  the  state,  the 
billing.  We  use  the  TLA+  syntax  for  writing  service  specifications,  as  follows: 

COEF  =  0..100  used  to  define  the  percentage  for  contributing  in  the  biling 

CALLS  = 

[party  :  SUBSET  USERS, 

linkcall  :  subset  (USERS  x  USERS), 

paycall  :  SUBSET  { USERS  x  USERS  x  USERS  x  COEF  x  TIME  x  TIME) 
com  :  SUBSET  (USERS  x  USERS), 
state  :  C ALLSTATES] 

Variables  such  as  calls,  phones,  tones,  messages,  billings,  services  are  typed  according  to  the  following  typing 
invariant.  We  define  it  and  operations  or  actions  which  have  to  preserve  it. 

Typing-Variables.Invariant  = 

A  calls  €  CALLS 

A  phones  6  [USERS  ->  PHONESTATES]  ' 

A  tones  €  [USERS  -t  TONESTATES] 

A  messages  €  [USERS  -4  SUBSET  STRING] 

A  billings  €  USERS  x  COEF  x  USERS  x  COEF  x  TIME  x  TIME 

A  services  €  USERS  ->  SUBSET  SERVICES 

Now,  we  can  incrementally  add  new  operations  that  are  either  activated  by  users  or  customers,  or  by  the  telecom 
systems.  The  basic  service,  called  POTS,  provides  the  following  operations  : 

-  off-hook 


A  user  can  off  hook  the  phone  because  he/she  wants  to  call  somebody 
somebodyelse  is  calling  him/her.  The  switch  will  reply  either  by 
sending  a  dialtone  or  by  starting  the  communication.  ,  '  ' 
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OFFHOOKCALLINGiXcaller)  = 

A  phones'  =  [phones  !EXCEPT[Xca?Zer]  =  "offhook”] 

A  tones'  =  [tones  !EXCEPT[Jtcai!?er]  =  "notone"] 

A  UNCHANGED  <  tones,  calls,  messages,  billings,  t  > 

wairts' to'.c^l'soii!eBi64y:Pamely  in'tHe 

OFFHOOKRINGING{X,Y,Xcall)  = 

A  Xcall  £  calls 
A  {X,Y}  C  Xcall. party 
A  tones[X]  =  "ringing" 

A  tones\Y]  —  "ringbacktone" 

^  tones'  =  [[tones  !except[X]  =  "notone"]  !EXCEPT[y]  -  " notone"] 

/\  phones[Xcalled\  ^  " o^ooV!'  =>  phones'  =  [p/iones  !EXCEPT[Xca/fer]  =  "offhook"] 

A  phones[XcaUed]  =  "offhook"  =>  phones'  =  phones 

A  UNCHANGED  <  calls,  messages,  billings,  t,  services  > 

Xcalled  is  called  by  somebody  else  and  Xcall ed  is  ringing;  .  ] 

the  operation  is  done  by  the  user 

-  on-hook 

-  dial 

-  communication 

We  have  added  an  event  which  is  executed  infinitly  often  to  model  the  time,  since  we  need  to  specify  the  starting 
point  of  a  call  and  the  ending  point  of  a  call,  for  instance. 

TICTAC  i.  At'  =  t  +  l 

A  UNCHANGED  <  tones ,  Calls ,  messages ,  billings ,  phones ,  services  > 

The  global  system,  called  POTS,  is  operationally  defined  as  a  disjunction  of  relations  over  primed  and  unprimed 
variables  (thanks  to  TLA) . 

we  define  the  set  of  possible  events  of  the  basic  system,  called 
POTS 


EventsBasicSystem  =  U  OffHookCallingEvents 
U  OffHookRingingEvents 
U  OnHookFirstEvents 
U  UpdateCallsEvents 
U  FinalUpdateCallEvents 
U  OnHookLastEvents 
U  DialEvents 
U  SendingToneDialevents 
U  DialToneEvents 
U  GommunicationOkEvents 
U  GommunicationDownEvents 
U  CommunicationBusyEvents 
U  OnHookDownEvents 
U  OnHookBusyEvents 
U  Clean-DowmCallsEvents 
U  Clean-Busy-CallsEvents 
U  Clean-Completed-Calls 
U  {TICTAC] 

Mow  we  apply  the ’Next’  pphra.t6r  to  obtain  the  next  relation 
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for  the  operational  seinsmtics;  :^^^ 


NextBasicSystem  =  Next{EventsBasicSystem) 

TLA$+$  requires  that  we  specify  the  variables  of  the  systehii :  •  -  ^ 

VarsBasicSystem  =  <  messages,  calls, phones,  tones,  billings,  t,  services  > 

Finally,  we  assume  that  every  event  is  executed  under  weak  fairness 
■assumption.  ’  -vV  ' '  ■  if 


FaimessBasicSystem  =  WF  {VarsBasicSystem,  EventsBasicSsystem) 

We  have  defined  an  operator  assigning  a  formula  from  a  set  of  formulae;  it  allows  us  to  get  a  simpler  way  to 
specify,  since  we  have  to  give  the  set  of  possible  events  and  to  apply  it  on  the  current  set  of  events.  Now  the 
bare  basic  service  is  simply  specified  by  the  following  formulae. 

InitBasicSystem  = 

A  calls  =  {} 

A  Vp  £  USERS  :  phones [p]  =  "on hook" 

AVp  €  USERS  :  tones [p]  =  "notone" 

A  billing  =  {} 

A  Vp  £  USERS  :  messages\jf^ 

A  Vp  .6  USERS  :  seraces [p]  =  {"basic"} 

Af  0 


SpecificationBasicSystem  = 

A  InitBasicSystem 

A  U[NexIBasicSystem].{  VarsBasicSystem} 
A  FaimessBasicSystem 


The  basic  system  provides  the  user  basic  functionalities  required  for  calling  somebody  else.  At  this  stage,  a  user 
X  can  call  only  one  user  Y‘;  if  we  increase  the  possibility  of  calling,  we  add  a  new  functionality  related  to 
a  new  service  Increasing  the  basic  functionalities  means  that  we  allow  the  user  additional  operations;  if  N  is 

n.m?  F  ""  ^  functionality  is  obtained  by  adding  another  relation, 

namely  F  as  follows  N  V  F.  Composing  is  reduced  to  logical  operations  over  relations  on  states,  but  we  may 

view  of  the  service  is  like  a  reactive  system.  The  modules  for 
PU  ib  have  a  very  restricted  scope,  since  the  functionality  of  each  is  very  limited. 


4.2  Adding  a  new  service 

The  user’s  view  deds  with  operations  such  as  subscribing,  unsubscribing,  paying,  billing,  and  a  service  is  gener¬ 
al  y  characterized  by  at  least  two  operations  that  enable  or  disable  the  service,  when  the  user  has  subscribed-  for 

^Tbus^ beSmS’idS^'^  user/subscriber  to  be  informed,  when  another,  whom  he  is  calling 


CCBS-activation(X)  = 

AX  £  USERS 

AX  ^  CCBS-sub 

A  CCBS.sub'  =  CCBS-sub  U  {A} 

A  CCBS.heap'  =  [s  G  DOM  CCBS-heap  U  {AT} 

i->  IF  a;  =  a:  then  {}  else  CCBS.heap[x]] 
A  UNCHANGED  <  list-of-unchanged-variables  > 

CCBS-inhibition{X)  = 

AX  £  USERS 
AX  £  CCBS-sub 


Gibson  P.,  Mery  D.  Formal  Modelling  of  Services 


115 


A  CCBS-suh'  =  CCBS-suh  -  {X} 

A  CCBSJieap'  =  [x  G  DOM  CCBSJieap  -  {X}  i->  CCBS-heap[x^^ 

A  UNCHANGED  <  list-of-unchanged.variahles  > 

It  modifies  the  basic  service,  by  strengthening  operations  of  the  callee;  moreover,  CCBS  is  a  very  interesting 
service,  since  it  requires  the  expression  of  a  fairness  constraint.  A  first  step  is  to  analyse  what  is  shared  by  CCBS 
and  POTS  and  what  is  private  or  local  for  CCBS.  We  introduce  two  variables  that  will  manage  the  current 
subscribers  of  CCBS  and  the  waiting  users  for  re-calling  somebody. 

VARIABLES 

CCBS-Sub,  set  of  users  that  have  Subscribed  to  CCBS 
CCBSJieap  function  defining  heaps  i  ^  ^ 

The  typing  invariant  of  CCBS  declares  the  role  of  those  variables. 

INVARIANT^CCBS  ^  A  CCBSsub  C  USERS 

A  CCBS-heap  G  [USERS  -4  SUBSET  USERS] 

The  next  step  is  to  define  ’’side-effects”  on  events  of  the  basic  service.  CCBS  requires  an  event  for  dequeing 
recalls  for  users  having  subscribed  to  CCBS;  we  call  it  CCBS-Dequeue{X,Y,Xcall)  and  it  requires  a  fairness 
assumption. 

CCBS.Dequeue{X,Y,Xcall) 

A  tones[X]  =  "notone" 
h  phones[X]  =  "onhook" 

A  phones\Y\  —  "onhook” 

A  tones\Y]  =  "notone” 

AX  G  CCBS.sub 

A  tones'  =  [[tones  !bxcept[X]  =  ”ringing"]!EXCBPT[F]  =  "ringing”] 

A  Xcall. state  =  "busyCCBS" 

A  Xcall  G  calls  n  CCBS-heap[Y] 

A  {X,  Y}  C  Xcall. party 

A  LET  newcall  =  CHOOSE  c  .  A  c  G  calls  P,  CCBS-heap[Y] 

A  estate  =  "waiting" 

A  c.com  —  Xcall.com 
A  c.paycall  =  Xcall.paycall 
A  c.linkcall  —  Xcall. linkcall 
IN  A  calls'  —  calls  —  {Xcall}  U  {newcall} 

A  CCBS-heap'  =  [CCBS-heap  Iexcept]!"]  =  @  -  [Xcall)] 

A  UNCHANGED  <  messages, phones, billings,  ccillsj,  CCBS-sub  > 

Now,  we  modify  two  events  in  the  specification  of  the  basic  service,  namely  the  COMMUNICATION-BUSY, 
which  manages  calls  when  they  are  busy,  and  OFFHOOKRINGING,  which  manages  when  somebody  is  called 
and  this  phone  is  ringing.  Hence,  we  modify  events  of  the  basic  service  and  add  new  events. 
CBS-COMMUNICATION-BUSY {X,Y,  Xcall)  4 
A  Xcall  G  calls 
A  Xcall. state  =  "waiting” 

A  Xcall. party  =  {X,  F} 

AX  ^  Y 
A  3  c  G  calls  ; 

A  c  ^  Xcall 

A  phones[Y]  —  "offhook" 

A  tones\Y]  —  "talking” 

A  F  G  c.party 
A  c.state  =  "active” 

A  X  ^  c.party 
A  phones[X]  =  "offhook" 

A  tones[X]  "dialling” 


116 


Perspectives  of  System  Informatics’99 


A  LET  newcall  = 

CHOOSE  c  .  A  c  G  CALLS  \  calls 

A  estate  =  "busyCCBS” 

A  c.party  =  {X,  Y} 

A  c.com  =  {} 

A  c.paycall  =  {} 

A  c.linkcall  =  {<X, F>} 

IN  A  calls'  =  calls  —  {Xcall}  U  {newcall} 

A  CCBS-heap'  -  \CCBS-heap  !EXCBPT[]r]  =  @  U  {newcall}] 

A  tones'  =  [tones  !except[X]  =  "CCBStone"] 

A  UNCHANGED  <  phones,  messages,  billings,  t,  CCBS-suh  > 

CCBS.OFFHOOKRINGING{X,Y,  Xcall)  = 

A  Xcall  G  calls 
A  {X,  y}  C  Xcall. party 
AV  tones[X]  =  "ringing" 

V  tones\Y]  =  "ringing” 

A  <  X,Y  >  Xcall. linkcall 
AX  €  CCBS-sub 

A  phone$[X]  7^  "offhook"  A  phones'  =  [phones  !except[X]  =  "offhook”] 

A  tones'  =  [tones  !except[X]  =  "notone"] 

A  p/ioraes[X]  =  "offhook"  A  phones'  —  [p/iones  lEXCEPTfF]  =  "offhook"] 

A  tones'  =  [tones  !EXCEPT[y]  =  "notone"] 

A  UNCHANGED  <  calls,  messages,  billings,  t,  CCBS.sub,  CCBS.heap  > 

Now,  events  of  CCBS  are  defined  as  follows: 

CCBS-events  = 

U  UNION  I  {CCBS.activation,  USERS) 

U  UNION xlcCBSJnhihition,  USERS) 

U  UNION ilcCBS-Dequeue,  USERS,  USERS,  CALLS) 

U  UNION ■^{CCBS.OFFHOOKRINGING,  USERS,  USERS,  CALLS) 

However,  POTS  is  modified  by  the  service  CCBS,  by  restricting  COMMUNICATION  events  when  the  called 
user  is  busy;  in  fact,  it  leads  to  enqueue  the  busy  called  user.  We  define  a  restriction  of  the  POTS  service  which 
is  modified  and  then  we  define  a  way  to  instantiate  a  system,  defined  by  a  set  of  events. 

CCBS-Restriction{System}  = 

System  —  CommunicationBusyEvents 

U  UNION z{CCBS^COMMUNICATION.£USY,  USERS,  USERS,  CALLS) 

CCBSJnstance{System)  =  CCBS.Restriction{System}  U  CCBS-events 

Properties  of  CCBS  tells  us  that  when  somebody  (X)  calls  somebody  else  (Y)  and,  if  Y  is  busy,  when  Y  will  be 
on  hooked,  the  system  will  recall  X  and  Y.  X  and  Y  will  ring  together,  when  fairness  constraints  are  ensured. 

CCBSPlusBSEvents  =  CCBS-instance{EventsBasicSystem) 

SpecCCBSPlusBS  = 

A  InitBasieSystem 
AlnitCCBS 

A  □  [Next{CCBSPlusBSEvents)].  <  VarsBasieSystem,  VarsCCBS  > 

A  WF {VarsCCBS  U  VarsBasieSystem,  CCBSPlusBSEvents) 


THEOREM  SpecCCBSPlusBS  =»  □  INVARIANTXCBS 


f  ’X’  calls  ’Y’,  while  ’Y’  is  busy  and  ’XI  fiafe  sufesenbed '  ’CCBS 
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then  eventually  ’Y’  is  appended  to  the  waiting  heap  for  ’X’ 

THEOREM 

SpecCCBSPlusBS  ^ 

(□  {Calling{X,Y)  A  (X  £  CCBSsub  A  Busy{Y))'^  (X  £  CCBS.heap[Y])) 

if  ’X’  is  in  the  waiting  heap  of  ’Y’,  and  if  V  has  subscribed  CCBS, 
while  ’X’  IS  infinitly  often  busy,  then  eventually  ’X’  and  ’Y’  will  ■ 

ring  both 
THEOREM 

SpecCCBSPlusBS 

{X  £  CCBS.heap[Y]  A  □  (Y  €  CCBS-suh)  A  □  O  -i  Busy{X) 

(RingingBoth{X,  Y)) 


We  have  expressed  the  formal  modelling  of  the  basic  service  and  of  CCBS;  now,  we  have  to  verify  theorems  and 
to  validate  the  specifications. 


4.3  Coordinating  views 

Our  model  of  services  in  TLA"^  can  be  verified  and  validated  using  the  Atelier  B  toolkit.  This  means  that  we 
can  verify  invariants  using  a  coding  of  our  TLA  specifications  in  B.  Services  can  be  viewed  as  abstract  machines 
or  as  TLA+  modules.  The  coordination  of  views  means  that  properties  that  are  observed  in  each  model  are  not 
contradictory.  Our  model  of  services  in  TLA+  can  be  verified  and  validated  using  the  Atelier  B  toolkit,  since 
our  TLA"^  specifications  are  made  up  of  imperative  actions,  namely  actions  are  written  as  x'  =  fix)  where  f{x) 
is  an  expression  codable  in  B.  Services  in  TLA*^  can  be  viewed  as  B  abstract  machines,  but  this  leads  us  to 
forget  fairness  issues.  However,  it  means  that  we  got  a  framework  for  animating  and  verifying  the  B  view  of  a 
TLA+  specification.  It  is  clear  that  our  approach  is  based  on  the  use  of  a  theorem  prover  but  one  can  also  use 
a  model-checking-based  tool. 

4.4  Validation  and  Verification 

We  give  a  graphical  representation  of  our  formal  models.  The  graphical  syntax  is  informally  explained  and,  where 
appropriate,  we  comment  on  how  the  formal  meaning  is  captured  using  LOTOS,  B  and  TLA.  The  semantics  are 
clearly  based  on  a  state  transition  model  and,  as  such,  are  easily  communicated  to  the  client  through  a  process 
of  animation. 

We  have  specified  a  simple  (POTS)  client-oriented  model  of  phone  behaviour.  This  is  sufficiently  complex  to 
illustrate  the  graphical  syntax,  in  figure  5,  being  employed  to  communicate  the  formal  semantics  with  the  client. 
The  following  aspects  of  the  specification  should  be  noted: 

The  header 

The  name  of  the  class  (Phone)  being  specified  is  given  first  in  the  header  of  the  diagram.  The  other  classes 
which  are  used  in  the  specification  of  the  new  class  are  listed  after  the  USING  keyword:  the  Phone  uses  classes 
signal  and  on-off. 

The  interface 

The  interface  to  the  class  is  represented  by  the  connections  at  its  boundary.  Each  connection  corresponds  to 
a  service.  In  this  case  there  are  5  services,  namely:  lift,  drop,  dial,  listen  and  regard.  Lift,  drop  and 
dial  correspond  to  transformer  services.  When  requested  they  result  in  a  state  transition.  Listen  and  regard 
correspond  to  accessor  services.  When  requested  they  return  a  value  to  the  service  requester.  The  type  of  the 
value  returned  is  identified  by  a  class  name:  listen,  for  example,  returns  a  signal  value.  Services  can  be 
parameterised  by  a  set  of  input  classes:  dial,  for  example,  is  parmeterised  by  an  ID  value.  Services  can  be 
polymorphic  on  their  input  classes.  In  other  words,  a  class  can  have  two  different  services  of  the  same  name 
provided  they  can  be  distinguished  by  the  types  of  their  input  parameters.  The  user  of  the  class  sees  the  class  as 
a  black  box.  The  internal  state  of  the  class  is  encapsulated  by  its  interface.  The  only  access  to  state  information 
is  through  the  accessors.  (There  is  one  more  type  of  service  which  is  not  illustrated  by  the  Phone:  the  dual 
service  is  a  combination  of  a  transformer  and  an  accessor,  it  returns  a  value  and  results  in  a  state  transition.) 
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Communication 

Communication  between  an  object  server  and  its  environment  of  clients  is  taken,  unless  othenvise  specified,  to 
be  synchronous.  This  may  lead  to  situations  in  which  services  are  requested  but  are  not  enabled  by  the  server. 
We  note  that  accessor  services  are  always  enabled.  Duals  and  transformers  may  not  always  be  enabled:  if  a 
chent  requests  a  service  which  is  not  enabled  then  it  is  the  client’s  responsibility  to  avoid  a  potential  deadlock 
situation.  One  role  of  fairness  in  our  models  is  to  gurantee  that  services  will  be  eventually  enabled. 

The  operational  semantics 

There  are  eight  states  m  the  Phone  class.  Thus  every  Phone  instance  (object)  must  be  in  one  of  these  eight 
states.  These  states  are  represented  as  nodes  in  the  inside  of  the  class  boundary.  For  each  state,  each  of  the 
accessor  values  must  be  defined.  To  aid  compositional  specification  techniques,  and  to  facilitate  the  specification 
ol  classes  with  large  (potentially  infinite)  numbers  of  states,  we  can  define  a  class  to  be  structured  as  a  set  of 
component  classes.  Then,  these  internal  state  values  can  be  used  to  define  the  external  accessor  values.  This 
provides  a  degree  of  implementation  freedom  and  emphasises  that  internal  details  are  hidden  to  the  outside. 
In  the  Phone  example,  there  is  no  structure  definition  as  the  number  of  states  is  manageable  without  one  The 
mitial  state  of  an  object  on  creation  is  specified  by  a  bold  pointer  which  does  not  originate  from  another  state. 
Hence,  a  Phone  always  starts  on  and  silent.  The  state  transitions  which  occur  in  response  to  an  external 
service  request  are  represented  by  solid  pointers  from  old  to  hew  states. 

Invariants 

State  invariant  properties  define  restrictions  on  the  possible  sets  of  component  values.  For  example,  as  is  shown  in 
figure  5,  we  may  require  that  when  onhook  the  Phone  must  be  ringing  or  silent.  These  properties  are  verified 
for  more  complex  cases,  using  B:  by  checking  that  all  transitions  are  closed  with  respect  to  the  invariant  it  is 
not  necessary  to  examine  every  single  reachable  state  (which  we  can  do  directly  with  the  simple  Phone  model) 
Note  that  the  state  invariants  specified  in  this  way  are  explicit  requirements  of  the  client  that  must  be  respected 
by  the  model.  A  specification  where  the  invariants  are  not  true  is  said  to  be  contradictory. 

Nondeterminism 


Nondetermmism  is  formalised  as  internal  state  transitions  that  may  occur  independent  from  external  service 
requests.  These  are  represented  by  (possibly  labelled)  dotted  pointers  from  old  to  new  states.  For  example,  when 
off  and  connecting  the  Phone  user  has  no  control  over  whether  the  number  they  are  trying  is  busy,  free  or 
if  noconnection  is  possible.  These  three  cases  are  specified  rising  internal  actions  (labelled  appropriately).  The 
difference  between  internal  and  external  actions  specifies  a  point-of-view  onto  a  class  (and  the  objects  of  the 
cl^s).  In  this  paper,  our  models  specify  the  Phone  user’s  point  of  view  (or  abstraction).  The  way  in  which  the 
telephone  network  interacts  with  the  Phone  is  abstracted  away  from  in  the  form  of  nondeterministic  transitions. 
Certainly,  it  is  necessary  to  specify  other  points  of  view  when  modelling  the  whole  telephone  network  Our 
rcfmXtTrr?  T  liferent  abstractions  and  then  helps  us  to  integrate  these  abstractions  into 

F^rnL?  ^  beyond  the  scope  of  this  paper,  which  concentrates  on  user  requirements. 

Liveness  conditions  can  be  specified  on  the  nondeterministic  events  in  the  model.  For  example,  we  may  require 
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that  when  off  and  connecting  the  user  does  not  wait  forever  for  a  state  transition  if  they  refuse  to  drop  the 
phone.  This  must  be  specified  in  a  separate  TLA  (temporal)  clause.  In  figure  5,  we  specify  weak  fairness  on  the 
no  c  onne  ct  i  on  action . 

(In)finite  processes 

A  Phone  is  an  infinite  process.  In  later  examples  we  specify  finite  behaviours  which  EXIT  after  some  specific 
behaviour  is  fulfilled.  A  Phone  is  said  to  be  of  type  NOEXIT. 

A  new  feature:  black  list  , 

The  Black  List  feature  has  a  similar  function  to  originating  call  screening,  but  restricts  incoming  rather  than 
outgoing  calls.  The  idea  is  that  you  can  store  a  list  of  numbers  that  you  know  you  do  not  wish  to  talk  with  and 
then  your  phone  does  not  ring  when  such  numbers  are  the  source  of  an  incoming  call.  Our  specification  of  this 
feature  is  illustrated  in  figure  6. 


PhonefBIackL5st=Phone![diann]|BladcHst 


Fig.  6.  Black  list 


Again,  we  have  some  comments  to  make  with  regard  to  this  feature  model: 

Composition  Re-Use 

The  composition  is  precisely  that  seen  for  a  similar,  better  known.  Caller  ID  feature:  there  is  internal  synchro¬ 
nisation  on  the  dialln  event  and  the  system  depends  on  an  action  refinement  in  the  network  to  carry  the  new 
identification  data  using  a  dialInFrom  action. 

Phone  refinement 

Unlike  CalllD,  not  all  dialInFrom  actions  result  in  a  dialln  action:  the  blacklist  filters  out  all  incoming  dials 
which  are  stored  in  the  list  of  numbers  in  its  state.  However,  like  CalllD,  from  the  point  of  view  of  the  user  the 
new  system  is  a  refinement  of  the  old  phone  —  the  only  difference  is  the  resolution  of  some  of  the  nondeterminism 
in  the  original  phone  model. 

Weak  fairness  guarantees  eventuality 

We  require  weak  fairness  on  the  dialln  event  in  the  Blacklist  component.  In  the  Blacklist  component 
we  see  that  after  a  dialInFrom  event,  the  external  services  removelD  and  addID  may  not  be  enabled  until  a 
dialln  action  is  performed,  in  the  case  where  the  number  is  not  black  listed.  However,  weak  fairness  on  dialln 
guarantees  that  this  transition  will  eventually  occur.  Thus,  we  guarantee  that  the  telephone  user  will  not  be 
deadlocked  if  they  wish  to  add  or  remove  a  number  from  the  blacklist  because  of  an  incoming  call. 
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Localisation 

At  first  glance  this  feature  seems  to  be  local.  All  other  users  of  the  telephone  system  can  remain  unaware  of 
this  particular  feature  at  any  given  phone.  However,  we  have  abstracted  away  from  an  implementation  detail 
which  has  global  eSect:  what  signal  should  a  caller  hear  if  they  telephone  someone  who  has  black  listed  them? 
there  are  a  number  of  choices; 

A  new  type  of  signal  telling  them  that  they  have  been  blacklisted. 

This  may  not  be  acceptable  from  a  social  point  of  view  -  do  you  really  want  someone  to  know  that  you 
don’t  wish  to  talk  to  them.  ^ 

-  A  noconnected  signal. 

This  may  not  be  acceptable  since  the  caller  may  misinterpret  the  signal  as  saying  that  the  number  they  are 

V  iTl  impossible  to  connect.  Furthermore,  an  intelligent  user  may  realise  why  they  are  unconnected, 
which  brings  us  back  to  the  first  problem. 

-  A  busy  signal. 

This  may  be  unaccepteble  since  the  caller  may  continue  dialling  because  they  think  the  person  they  are 
trying  to  contact  will  be  available  as  soon  as  their  current  call  is  completed. 

-  A  ringing  signal. 

Tlus  seems  to  be  the  most  acceptable  choice,  and  in  our  network  model  we  specified  the  feature  in  this  way 
Thus  the  blacklist  service  required  only  local  change  to  the  telephone  user  which  requested  this  service.  All 
other  users  retain  their  original  behaviour. 

It  is  only  through  animation  that  a  user  can  be  expected  to  understand  such  choices  and  help  the  designers  to 
resolve  the  nondeterminism.  ° 

5  Conclusion 

The  problem  of  telephone  feature  interaction  is  just  a  particular  instance  of  a  general  problem  in  software 
S f problem  occurs  when  we  consider  inheritance  in  object  oriented  systems,  sharing  data 
d  stributed  systems,  imlti-way  synchronisation  in  systems  of  concurrent  processes,  etc  ... .  However  the 
problem  is  particularly  difficult  in  telephone  systems  because  features  are  the  increments  of  development  ’ 

We  have  shown  the  importance  of  re-usable  composition  mechanisms.  Although  our  work  is  targeted  towards 
the  client  during  requirements  capture,  we  believe  that  the  same  models  could  be  used  during  design  and  at  the 
network  level.  We  support  the  principle  of  developing  re-usable  analysis  techniques  based  on  re-usaS  syhnthesis 
echanisms.  The  object  oriented  approach  can  be  extended  to  include  a  classification  of  feature  types  and  we 
hope  to  map  this  onto  a  formal  algebra  for  feature  development. 

We  have  used  a  graphical  notation  for  communicating  with  the  customer.  However,  our  graphics  are  based 

wy  helpful  n  studying  the  coniplementary  nature  of  different  formalims.  Logical  formalisms  such  as  B  or 

analysis  of  services  based  on  proof  techniques.  Animation  is  made  easier  by 
automata- based  representations.  ^ 

This  work  is  dependent  on  the  different  view  points  and  the  different  semantic  models.  The  integration  of  these 
semantics  and  the  development  of  user-oriented  tools  is  the  most  important  element  of  our  current,  and  future 
th^T  integration  of  refinement-based  reasoning  is  an  important  point  to  develop,  with  experiments 
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Abstract.  The  verification  system  PVS  is  used  to  obtain  mechanized  support  for  the  formal  specification 
and  verification  of  concurrency  control  protocols,  concentrating  on  database  applications.  A  method  to 
verify  conflict  serializability  has  been  formulated  in  PVS  and  proved  to  be  sound  and  complete  with  the 
interactive  proof  checker  of  this  tool.  The  method  has  been  used  to  verify  a  few  basic  protocols.  Next  we 
present  a  systematic  way  to  extend  these  protocols  with  new  actions  and  cpntrol  information.  We  show 
that  if  such  an  extension  satisfies  a  few  simple  correctness  conditions,  the  new  protocol  is  serializable  by 
construction. 

1  Introduction  ' 

Concurrency  control  protocols  [SKS97,U1188],  when  applied  to  databases,  manage  the  concurrent  access  to  a 
database  by  multiple  users  or  processes.  Access  is  performed  by  means  of  transactions,  consisting  of  a  number 
of  actions  (such  as  reads  and  writes  of  data  items).  This  access  has  to  be  both  correct,  i.e.  always  leaving 
the  database  in  a  consistent  state,  and  efficient,  i.e.  providing  a  good  overall  performance.  One  of  the  most 
important  correctness  notions  is  serializability  of  transactions,  which  is  the  main  topic  of  this  paper. 

It  is  prominently  difficult  to  achieve  both  correctness  and  efficiency  at  the  same  time.  The  most  popular 
database  protocol,  the  Two  Phase  Locking  protocol  (2PL),  is  simple  and  ensures  serializability.  Although  it 
became  a  commercial  standard  in  the  seventies,  it  has  been  criticized  for  low  performance  and  the  possibility  of 
deadlock  (see,  for  instance,  [Tho93]).  A  number  of  more  efficient  database  protocols  has  been  suggested,  often 
on  top  of  basic  protocols  such  as  2PL.  Newly  developed  protocols  are  becoming  increasingly  complex,  and  their 
correctness  becomes  difficult  to  ensure.  Specification  and  reasoning  are  often  very  informal,  which  easily  leads  to 
ambiguous  specifications.  All  these  factors  make  the  understanding  and  the  use  of  these  new  protocols  difficult 
and  they  increase  the  danger  of  incorrect  protocols. 

To  address  this  problem,  observe  that  many  database  protocols  can  be  modeled  as  variations  of  a  few  basic 
concurrency  control  protocols.  Although  these  variations  can  be  obtained  in  different  ways,  they  can  often  be 
considered  as  extensions  of  a  basic  protocol.  An  extension  of  a  database  protocol  is  a  protocol,  which  includes 
more  control  information  (such  as  timestamps  and  versions)  and  corresponding  new  actions. 

The  aim  is  to  obtain  the  correctness  of  extensions  from  the  correctness  of  a  basic  protocol.  Here  we  focus 
on  only  one  important  correctness  notion,  namely  serializability.  An  interleaved  execution  of  a  number  of 
transactions  is  said  to  be  serializable,  if  it  has  the  same  effect  on  a  database  as  some  serial  execution  of  these 
transactions,  i.e.  an  execution  which  has  no  interleaving  between  actions  of  different  transactions.  Deadlocks 
are  assumed  not  to  occur  (as  e.g.  [U1188]),  since  they  do  not  influence  serializability. 

Given  some  set  of  basic  concurrency  control  protocols,  we  propose  to  prove  the  correctness  of  extensions 
of  these  protocols,  using  the  following  strategy:  a)  Prove  correctness  (i.e.  serializability)  of  the  basic  protocols, 
b)  Derive  the  correctness  of  the  extensions  in  a  systematic  way,  using  some  assumptions  on  their  construction. 
Ideally,  this  should  be  done  in  a  structured  way,  using  some  mechanical  support.  The  aim  of  our  paper  is  to 
suggest  a  method  to  implement  this  strategy.  Therefore,  we  address  the  following  questions:  1)  How  to  obtain 
mechanical  support  for  specification  and  verification?  2)  How  to  model  concurrency  control  protocols?  3)  How 
to  formalize  serializability?  4)  How  to  verify  serializability?  5)  How  to  formalize  protocol  extensions  and  which 
conditions  are  needed  to  ensure  their  correctness? 

1)  Mechanical  support.  To  get  mechanical  support,  we  use  a  higher-order  interactive  theorem  prover, 
since  notions  like  serializability  are  easily  expressed  in  a  property-oriented,  assertional,  way.  To  express  general 
properties  about  these  notions,  that  hold  for  all  protocols,  a  higher-order  logic  is  needed.  Since  we  would  like 
to  use  arbitrary  data  types  and  not  restrict  ourselves  to  finite  state  systems.  Completely  automatic  verification 
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IS  not  feasible.  Although  there  are  several  verification  systems  that  satisfy  our  requirements,  we  have  chosen  to 
use  PVS  [PVS],  because  it  has  a  convenient  specification  language  and  is  relatively  easy  to  learn  and  to  use. 

The  specification  lan^age  of  PVS  is  a  strongly-typed  higher-order  logic.  Specifications  can  be  structured  into 
a  hierarchy  of  parameterized  theories.  There  is  a  number  of  built-in  theories  and  a  mechanism  for  constructing 
abstract  datatypes.  The  PVS  system  contains  an  interactive  proof  checker  with,  for  instance,  induction  rules, 
automatic  rewriting,  and  decision  procedures  for  arithmetic.  It  allows  users  to  construct  proofs  interactively,  to 
discharge  siiriple  verification  conditions  automatically,  and  to  check  proofs  mechanically. 

2)  Specification  of  protocols.  To  model  a  particular  protocol  in  PVS,  we  define  two  types:  1)  Actions, 
such  as  read  and  write,  and  possibly  additional  actions  necessary  for  the  adjustment  of  the  control  information  2) 
States,  representing  control  information  (locks,  timestamps,  etc.);  and  two  predicates:  3)  Effect,  defining  how 
a  state  is  changed  after  applying  a  particular  action  4)  Pre,  defining  which  actions  are  allowed  id  a  particular 
state,  and  which  are  not. 


3)  Serializabihty  notions.  A  schedule  is  a  sequence  of  actions  by  transactions!  Intuitively,  a  schedule  is 
considered  to  be  correct,  if  it  is  equivalent  to  some  serial  schedule.  Serial  schedules  are  those  which  have  no 
mterleaving  between  actions  of  different  transactions.  There  are  different  ways  to  define  equivalence  of  schedules. 
The  most  intuitively  appealing  one  leads  to  the  notions  of  view  equivalence.  Informally,  two  schedules  are  view 
equivalent  iff  each  transaction  in  these  schedules  reads  the  values  written  by  the  sanle  transaction.  A  schedule 
is  said  to  be  view  serializable,  if  it  is  view  equivalent  to  some  serial  schedule.  Testing  view  serializabihty  is  NP- 
complete  [Pap79],  and  therefore  this  notion  is  difficult  to  use  in  practice.  Another  form  of  schedule  equivalence 
is  conflict  equiva.Ience,  leading  to  conflict  serializabihty.  Two  schedules  are  conflict  equivalent  iff  one  of  them  can 
be  transformed  into  the  other  by  a  sequence  of  swaps  of  non-conflicting  actions.  Testing  conflict  serializability 
has  a  quadratic  complexity,  and  therefore  the  majority  of  existing  database  protocols  ensures  not  just  view 
SGnalizabilityj  but  the  stronger  notion  of  conflict  serializability. 

We  formalize  the  notions  of  conflict  and  view  serializabihty,  and  prove,  that  any  conflict  serializable  schedule 
IS  also  view  serializable.  This  relation  is  well  known  but  has  never  been  checked  mechanically.  In  fact,  there  is 
no  standard  definition  of  view  serializability  in  the  literature.  Here  we  combine  the  informal  intuition  of  fSKS97l 
with  the  reads-from  relation  of  [Vid91]. 

4)  Method  of  verification.  A  traditional  method  for  proving  conflict  serializability  is  based  on  conflict 
graphs.  Om  method  is  a  modification  of  this  traditional  method  and  does  not  use  any  notions  from  graph  theory. 
We  believe  that  our  method  is  logically  more  simple  and  straightforward,  and  therefore  more  appropriate  for 
mechanical  verification.  This  makes  it  possible  to  efficiently  implement  our  method  in  PVS. 


Our  method  is  based  on  the  notion  of  conflict-preserving  timestamps  (CPT).  We  formulate  a  condition  for 
schedules  to  be  conflict  serializable  using  an  assignment  of  timestamps  to  transactions  which  orders  conflicting 
transactions  (two  transactions  are  conflicting  iff  at  least  one  of  them  contains  a  write  to  a  common  data 
Item).  We  prove  that  this  condition  is  necessary  and  sufficient.  Hence,  to  show  that  a  protocol  ensures  conflict 
serializability,  we  must  prove  that  any  schedule  accepted  by  this  protocol  satisfies  the  condition.  This  implies 
then  that  the  protocol  indeed  ensures  conflict  serializability,  as  well  as  the  weaker  notion  of  view  serializability. 

5)  Extensions  and  correctness  conditions.  Suppose  some  basic  protocol,  for  ijtistance  the  2PL  protocol 
M  been  proved  correct.  Adding  more  control  information  and  more  actions,  we  obtain  various  extensions  of 
this  protocol.  We  show  that  serializability  of  these  extensions  is  ensured  by  four  simple  correctness  conditions 
Ihe  proof  that  these  conditions  lead  to  serializable  protocols  is  far  from  trivial,  but  has  to  be  done  only  once 
By  applying  the  resulting  extension  scheme,  we  easily  obtain  protocols  that  are  serializable  by  construction 


As  an  example,  we  consider  the  2PL  protocol  and  several  layered  extensions.  In  the  basic  protocol,  serial- 
izabflity  IS  ensured  by  locking  and  unlocking  data  items.  The  first  extension  adds  sequences  of  transactions 
wmtmg  for  data  items  to  become  a,vailable  (i.e.,  unlocked).  The  second  extension  gives  priority  to  urgent  trans¬ 
actions,  resulting  m  a  more  realistic  protocol.  Since  we  formally  verified  the  correctness  of  the  2PL  protocol  a 
simple  check  of  the  four  conditions  leads  to  the  correctness  of  these  new  protocols. 

Struct^e  of  this  paper.  This  paper  is  organized  as  follows.  In  section  2,  we  provide  a  general  specification 
pattern  and  apply  it  to  the  specification  of  the  2PL  protocol.  In  section  3,  the  notions  of  conflict  and  view 
seridizability  axe  formalized.  We  prove  that  conflict  serializability  implies  view  serializability.  In  section  4  our 
verification  method  is  presented  and  its  soundness  and  completeness  are  shown.  The  method  has  been  applied  to 

Timestamp  Ordering  protocol.  In  section  5,  we  formalize  extensions  of  protocols 
and  the  restrictions  on  these  extensions,  needed  to  ensure  their  correctness.  In  section  6,  we  apply  our  method  to 
specify  and  verify  several  layered  extensions  of  the  2PL  protocol.  Section  7  contains  some  concluding  remarks 
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2  Specification  of  protocols 

We  consider  protocols  in  which  transactions  perform  atomic  actions  on  certain  data  items.  Two  basic  actions 
are  common  for  such  database  protocols:  read  and  write,  which  are  the  only  actions  that  concern  the  values 
of  the  data  items.  Additionally,  there  are  usually  other  actions,  necessary  for  the  concurrency  control.  The  set 
of  actions  of  a  database  protocol  is  defined  by  type  ActionNames,  containing  at  least  read  and  write  actions 
(denoted  as  R  and  W).  In  the  PVS  notation  (henceforth  written  in  typewriter  style): 

R,  W  :  ActionNames 

The  set  of  data  items  is  defined  by  uninterpreted  type  Variables;  the  set  of  transactions  is  defined  by  type 
Transactions,  representing  the  names  of  transactions.  Moreover,  we  define  a  type  Actions  consisting  of  records 
with  three  fields,  called  act,  tr,  and  vari,  expressing  that  a  particular  action  is  performed  by  a  transaction  on 
a  data  item. 

Actions  :  TYPE  =  [#  act  ;  ActionNames,  tr  :  Transactions, 
vari  :  Variables  #] 

» 

E.g.,  (W,  T,  x)  represents  a  write  action  by  transaction  T  on  variable  X. 

Concurrency  control  protocols  maintain  a  control  part  to  determine  which  actions  on  data  items  are  allowed 
and  which  are  not  allowed  in  a  particular  state  of  a  database.  E.g.,  the  control  part  for  lock-based  protocols 
determines  which  data  items  are  locked  and  in  which  mode  (shared  or  exclusive)  ..The  control  part  for  timestamp- 
based  protocols  contains  information  about  timestamps  of  data  items.  In  PVS,  the  control  part  for  database 

protocols  is  defined  by  type  States.  i  •  i  i 

Each  action  causes  certain  changes  in  the  control  part.  For  example,  for  lock-based  protocols,  it  may  lock 
or  unlock  some  data  items.  For  timestamp-based  protocols,  this  concerns  the  adjustment  of  read-  and  write- 
timestamps  of  some  data  items.  Therefore,  we  define  the  initial  value  of  the  control  part,  i.e.  the  initial  state, 
and  how  the  control  part  is  changed  after  every  possible  action.  We  also  have  to  define  which  actions  are  allowed 
in  a  particular  state,  and  which  are  not.  E.g.,  a  transaction  cannot  lock  a  data  item  in  an  exclusive  mode  if  it 
is  already  locked  by  another  transaction.  Consequently,  a  database  protocol  is  defined  by  the  following  steps: 

1.  Define  type  ActionNames,  containing  the  atomic  actions  R  and  W  and  possibly  some  other  atomic  actions, 
responsible  for  the  adjustment  of  control  information. 

2.  Define  type  States,  containing  all  control  information  essential  for  the  definition  of  the  protocol,  and  define 

the  initial  state  is.  \  .  /  j  -if 

3.  Define  how  a  particular  state  is  changed  after  applying  a  particular  (allowed)  action  (e.g.,  a  read  or  write  ot 
a  data  item)  by  means  of  the  Effect  predicate;  a  function  with  three  arguments  of  types  States ,  Actions, 
States,  resp.,  and  result  of  type  bool.  For  states  si  and  s2  and  an  action  al,  we  have  Effect  (si,  al, 
s2)  =  TRUE  iff  s2  is  obtained  from  si  by  applying  al. 

4.  Define  which  actions  are  allowed  in  a  particular  state  by  the  Pre  predicate.  For  a  state  si  and  an  action  al 

we  have  Pre  (si,  al)  =  TRUE  iff  al  is  allowed  in  si.  ' 

A  finite  execution  is  represented  by  a  sequence  r  of  ^he  form  sq  ^  Si  ^  •••  ®n  Sn+i-  Here  Si  (0  <  i  <  n  +  1) 
are  states,  and  ««  (0  <  i  <  n)  are  actions.  Infinite  executions  are  represented  by  all  finite  approximations. 
Sequence  r  is  a  correct  execution  or  run  iff  so  is  the  initial  state,  subsequent  states  are  related  by  the  Effect 
predicate,  and  actions  are  enabled,  as  expressed  by  the  Pre  predicate. 

In  PVS,  a  run  r  is  formalized  as  a  record  with  two  fields:  StateSeq(r)  is  a  finite  sequence  of  states,  and 
ActionSeq(r)  is  a  finite  sequence  of  actions,  where  StateSeq(r)  has  one  more  element  then  ActionSeq(r). 
For  the  example  run  above,  we  have  StateSeq(r)  =  so®i-"®n®n-(-i  mid  ActionSeq(r)  -  aocti...Bn- 

A  finite  sequence  of  actions  is  called  a  schedule.  For  instance,  (W,  Tl,  x)  (W,  T2,  y)(R,  Tl,  y)  represents 
an  execution  where  first  transaction  Tl  writes  a  data  item  x,  then  transaction  T2  writes  a  data  item  y,  and  next 

Tl  reads  y.  ,  ,  .  .  i 

For  a  protocol,  represented  by  States,  is,  Actions,  Effect  and  Pre,  and  a  run  r  of  this  protocol,  we  say 

that  ActionSeq(r)  is  a  schedule,  allowed  by  this  protocol  Given  a  definition  by  the  four  points  mentioned  above, 
we  identify  a  protocol  with  the  set  of  allowed  schedules. 

protocol  ;  setof  [Schedules]  = 

i  S  :  Schedules  I  EXISTS  (r  :  Runs)  :  S  =  ActionSeq(r)  } 
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2.1  Example  of  the  Two  Phase  Locking  protocol 

Informal  description.  The  2PL  protocol  (see,  e.g.,  [SKS97])  requires  that  access  to  data  items  is  done  in  a 
mu Jally  exclusive  manner;  that  is,  while  one  transaction  is  accessing  a  data  item,  no  other  transaction  can 
modify  that  data  Item.  The  most  common  method  used  to  implement  this  requirement  is  to  allow  a  transaction 
to  access  a  data  item  only  if  it  is  currently  holding  a  lock  on  that  item.  There  are  various  modes  in  which  a 
data  Item  may  be  locked.  The  basic  2PL  protocol,  considered  in  this  paper,  has  only  two  modes; 

-  Shared.  If  a  transaction  T  has  obtained  a  shared-mode  lock  on  item  x,  then  T  can  read,  but  cannot  write, 

-  Exclusive.  If  a  transaction  T  has  obtained  an  exclusive-mode  lock  on  item  x,  then  T  can  both  read  and 

Let  A  ^d  B  represent  arbitrary  lock  modes.  Suppose  that  transaction  T2  requests  a  lock  of  mode  B  on  item  x  on 
which  transition  T1  (T1  #  T2)  currently  holds  a  lock  of  mode  A.  If  T2  can  be  granted  a  lock  on  x  immediately 
in  spite  of  the  ^ese^e  of  the  mode  A  lock,  then  we  say  that  mode  B  is  compatible  with  mode  A.  In  the  2PL 
protocd  shared  mode  i  compatible  with  shared  mode,  but  not  with  exclusive  mode;  exclusive  mode  is  not 
compatible  with  both  shared  and  exclusive  modes. 

f  ^  first  lock  that  item  in  the  corresponding  mode.  If  the  data  item 

IS  already  locked  m  an  incompatible  mode,  the  request  to  lock  this  item  is  rejected.  The  2PL  protocol  requires 
that  each  transaction  issues  lock  and  unlock  requests  in  two  phases: 

-  Growing  phase.  A  transaction  may  obtain  locks,  but  may  not  release  any  lock. 

Shrinking  phase.  A  transaction  may  release  locks,  but  may  not  obtain  any  new  locks. 

Initially,  a  tr^sition  is  in  the  growing  phase.  The  transaction  acquires  locks  as  needed.  Once  the  transaction 
releases  a  lock,  it  enters  the  shrinking  phase,  and  it  can  issue  no  more  lock  requests. 

VS  implementation.  We  specify  this  protocol,  following  the  four  steps  mentioned  above.  The  Eff  ect2PL 
predicate  and  the  Pre2PL  predicate  are  not  shown  here. 

“  model  locking  is  incorporated  in  read  and  write  actions,  and  hence  does  not  require  a 

separate  action.  We  only  add  an  unlock  action  to  unlock  a  data  item  which  is  locked  in  a  shared  or  exclusive 
mode  and  a  downgrade  action  which  changes  the  mode  of  the  lock  from  exclusive  to  shared. 

ActionNames2PL  :  TYPE  =  ■(  R,  W,  unlock,  downgrade  ]• 

~  ^  ^"d  sset  map  each  transaction  to  a  set  of  data 

^  “Ode,  respectively,  shrinking  is  a  set  of  transactions  which 

already  entered  the  shrinking  phase  and  therefore  cannot  issue  any  new  locks. 

States2PL  :  TYPE  = 

[#  xset  :  [Transactions  ->  setof [Variables]  ]  , 
sset  :  [Transactions  ->  setof [Variables]  ], 
shrinking  :  setof [Transactions]  #] 

In  the  initial  state,  is2PL,  all  the  data  items  are  unlocked  and  no  transaction  is  shrinking. 

3  View  and  Conflict  serializability 

To  defee  view  serializability,  we  first  define  view  equivalence  between  schedules,  following  fSKS97l.  Consider 
wo  schedules  SI  and  S2,  where  the  same  set  of  transactions  participates  in  both  schedules. 

Definition  1.  The  schedules  SI  and  S2  are  view  equivalent  the  following  three  conditions  are  met: 

1.  For  each  data  item  x,  if  transaction  T1  reads  the  initial  value  of  x  in  schedule  SI  then,  in  schedule  S2 
transaction  T1  must  also  read  the  initial  value  of  x  ’ 

ZZlaZS.  •  «»'»*  ■>/*  that  wa,  produced  bl 

«  as  any)  that  performs  ike  last  write  action  on  T  in  schedule  SI 
must  also  perform  the  last  write  action  on  x  in  schedule  S2.  »cneame  bi, 
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Conditions  1  and  2  ensure  that  each  transaction  reads  the  same  values  in  both  schedules  and,  therefore,  performs 
the  same  computation.  Condition  3,  coupled  with  conditions  1  and  2,  ensures  that  both  schedules  result  in  the 
same  final  system  state. 

The  definition  of  view  equivalence  can  be  presented  in  a  more  formal  way  using  the  notion  of  a  reads- 
from  relation  [Vid91].  We  associate  with  each  schedule  S  a  reads-from  relation  Reads_froin(S),  not  shown 
here,  relating  a  transaction  that  read  a  value  of  an  item  and  the  transaction  that  wrote  this  value.  Then  view 
equivalence  can  be  defined  as  follows. 

Definition  2.  (Equivalent  to  1.)  The  schedules  SI  and  S2  are  view  equivalent  if  their  reads-from  relations  are 
equal: 

view_equiv(Sl,  S2)  :  bool  =  (Reads_from(Sl)  =  Reads _froin(S2)) 

As  we  mentioned  in  introduction,  a  schedule  is  serial,  in  PVS  represented  by  predicate  serial (S),  if  it  has  no 
interleaving  between  actions  of  different  transactions.  For  instance,  schedule  (W,  T2,  y)(W,  Tl,  x)(R,  Tl, 
y)  is  serial,  because  an  action  by  T2  precedes  both  actions  by  Tl.  Schedule  (W,  Tl,  x)  (W,  T2,  y)  (R,  Tl, 
y)  is  not  serial,  because  two  actions  by  Tl  are  interleaved  by  an  action  by  T2. 

A  schedule  S  belongs  to  the  set  of  view  serializable  schedules,  denoted  byView-serializable,  iff  it  is  view 
equivalent  to  a  serial  schedule.  • 

View_serializable  :  setof [Schedules]  = 

■[  S  I  EXISTS  SO  :  serial  (SO)  AND  view_eqMv(S,  SO)  } 

Next  we  explain  the  notion  of  conflict  equivalence.  Suppose  S  includes  two  consecutive  actions  al  =  (A1 ,  Tl , 
x)  anda2  =  (A2,  T2,  y),  where  Al  and  A2  belong  to  {  R,  W  }.  Thus  S  =  SI  al  a2  S2  for  some  subschedules 
SI  and  S2.  As  explained  in  [SKS97],  the  order  of  al  and  a2  does  not  influence  the  result  of  computation  if  either 
X  ^  y  or  (x  =  y  and  Al  =  A2  =  R).  If  x  =  y  and  (Al  =  W  or  A2  =  W),  then  the  order  of  al  and  a2  matters,  i.e. 
changes  the  result  of  computation.  Observe  that  Tl  =  T2  is  allow’ed,  assuming  that  actions  of  a  transaction  are 
partially  ordered  rather  than  totally  ordered  as  in  [SKS97]. 

Definition  3.  The  actions  (Al,  Tl,  x)  and  (A2,  T2,  y)  ore  conflicting  iffx  =  y  and  (Al  =  W  or  A2  =  W). 

Definition  4.  The  schedules  SI  and  S2  are  elementary  equivalent  iff  SI  =  S3  al  a2  S4,  S2  =  S3  a2  al  S4 
and  the  actions  al  and  a2  are  not  conflicting. 

Definition  5.  The  schedules  SI  and  S2  are  conflict  equivalent,  denoitedconf_equiv(Sl,S2)  iff  there  is  a  finite 
sequence  of  schedules  S_0,  S_l, .  .  .SJk,  k  >=  0,  such  that  SI  =  S_0,  S2  =  SJs  and  for  all  i  <  k  the  schedules 
S-i  and  S_(i  +  1)  are  elementary  equivalent. 

A  schedule  S  belongs  to  the  set  of  conflict  serializable  schedules,  denoted  by 
Conf -serializable,  iff  it  is  conflict  equivalent  to  a  serial  schedule. 

Conf -Serializable  :  setof [Schedules]  = 

{  S  I  EXISTS  SO  ;  serial(SO)  AND  conf _equiv(S,  SO)  } 

Since  swaps  of  nonconflicting  actions  do  not  change  the  result  of  computation,  we  can  expect  that  they  do 
not  change  the  reads-from  relation  as  well.  Indeed,  y/e  have  proved  in  PVS  theorem  Conf  View,  expressing  that 
conflict  equivalent  schedules  SI  and  S2  are  also  view  equivalent; 

ConfView  :  THEOREM  Conf_equiv(Sl,  S2)  IMPLIES  View_equiv (SI,  S2) 

4  Our  method  of  verification 

We  present  a  general  method  for  mechanical  verification  of  conflict  serializability.  Our  approach  is  a  modification 
of  a  traditional  method  for  proving  conflict  serializability  based  on  conflict  graphs.  We  do  not  use  graphs,  but 
do  need  a  notion  of  conflicting  transactions  which  is  defined  as  a  conflict  relation. 

Definition  6.  A  conflict  relation  Conflict (S)  of  a  schedule  S  is  defined  as  follows:  a  pair  (Tl,  T2)  belongs 
to  Conflict  (S)  iffTl  ^  T2  and 

—  S  includes  actions  al  and  a2  by  Tl  and  T2  respectively 

—  al  precedes  a2  in  S 

—  al  and  a2  are  conflicting. 
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It  is  well-known  (although  not  mechanically  verified)  that  a  schedule  S  is  conflict  serializable  iff  the  relation 
Conflict  (S),  considered  as  a  graph  in  which  nodes  are  transactions,  is  acyclic.  Our  method  does  not  use  graph 
theory,  but  assigns  timestamps  to  transactions,  using  an  irreflexive  order  on  timestamps.  A  time  domain  Time 
is  some  domain  with  a  transitive,  irreflexive  order.  For  instance,  the  set  of  natural,  rational  or  real  numbers 
with  the  conventional  order.  A  timestamp  TS  is  a  function  from  Transactions  to  Time. 

Our  method  is  based  on  the  notion  of  conflict-preserving  timestamps  (CPT). 

CPT(S,  TS)  :  bool  =  FORALL  Tl,  T2:  Conflict (S) (Tl,  T2)  IMPLIES 

TS(Tl)  <  TS(T2) 

Definition  7.  A  timestamp  TS  is  a  conflict-preserving  timestamp  (CPT)  with  respect  to  schedule  S  iff  CPT (S 
TS)  =  TRUE. 

If  a  schedule  S  has  a  CPT  then  the  transitive  closure  of  Conflict  (S)  is  irreflexive,  because  <  is  an  irreflexive 
order  on  Time. 

A  schedule  S  belongs  to  the  set  of  ordered  schedules  Ordered  iff  there  is  a  timestamp  TS  which  is  conflict¬ 
preserving  with  respect  to  S. 

Ordered  :  setof  [Schedules]  =  ■(  S  |  EXISTS  TS  :  CPT(S,  TS)  } 

We  proved  that  any  ordered  schedule  is  conflict  serializable,  and  any  conflict  serializable  schedule  is  ordered. 
The  proof  has  been  constructed  by  means  of  the  interactive  proof  checker  of  PVS  and  is  technically  fairly 
complicated. 

OrdSerializable  :  THEOREM  Ordered  =  Conf_seriali2able 

Theorem  OrdSerializable  provides  a  basis  for  a  sound  and  complete  method  for  proving  serializability.  Given  a 
particular  protocol,  we  prove  that  each  schedule  allowed  by  this  protocol  is  ordered,  i.e.  has  a  conflict-preserving 
timestamp.  Thus,  for  a  particular  protocol,  the  aim  is  to  prove  the  following  theorem. 

ProtocolOrdered  :  THEOREM  subset? (protocol,  Ordered) 

After  that,  theorem  OrdSerializable  implies  that  protocol  indeed  ensures  conflict  serializability: 
ProtocolCS  :  THEOREM  subset? (protocol,  Conf_seriali2able) 

We  successfully  applied  our  method  to  the  machine-checked  verification  of  the  Timestamp  Ordering  protocol 
and  the  2PL  protocol. 


5  Extensions  of  (serializable)  protocols 

Although  we  have  formulated  in  the  previous  section  a  complete  method  to  prove  conflict  serializability,  it  is  not 
always  easy  to  find  a  conflict-preserving  timestamp  function  for  any  schedule  (and 'to  prove  that  it  actually  is 
one).  Observing  that  many  protocols  can  be  seen  as  extensions  of  a  basic  protocol  (such  as  Timestamp  Ordering 
or  2PL),  we  investigate  how  we  can  obtain  serializability  of  an  extension  from  serializability  of  a  basic  protocol. 
First  we  define  the  notion  of  an  extension  more  precisely. 

We  say  that  protocol  NewProt  is  an  extension  of  protocol  OldProt  iff 

-  OldActionNames,  the  set  of  atomic  actions  of  OldProt,  is  a  subset  of 
NewActionNames,  the  set  of  atomic  actions  of  NewProt. 

-  NewStates,  the  control  part  of  NewProt,  is  obtained  from  OldStates,  the  control  part  of  OldProt,  by  adding 
a  record  ext  of  type  Extension,  representing  the  added  control  information: 

NewStates  :  TYPE  =  [#  old  :  OldStates,  ext  :  Extension  #] 

Our  goal  IS  to  prove  that  if  OldProt  ensures  conflict  serializability  and  extension  NewProt  satisfies  certain 
conditions,  then  NewProt  also  ensures  conflict  serializability.  Below  we  derive  the  required  conditions  during  the 
construction  of  the  proof.  ' 

Let  Conf _ser_01d  and  Conf .serJIew  be  instantiations  of  set  of  schedules  Conf _serializable  for  schedules 
from  OldProt  and  NewProt,  respectively.  Our  aim  is  to  prove  the  following  theorem. 
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MainTheorem  :  THEOREM  subset? (OldProt,  Conf _ser_01d)  IMPLIES 

subset? (NewProt,  Conf _ser_New) 

Proof:  Suppose  OldProt  ensures  conflict  serializability  and  schedule' NewS  is  accepted  by  NewProt.  The  proof 
that  News  is  conflict  serializable  consists  of  two  steps. 

Step  1  We  prove  that  NewS  is  a  refinement  oi  some  schedule  OldS,  accepted  by  OldProt,  i.e.  it  is  obtained  from 
OldS  by  adding  some  actions.  To  construct  OldS,  we  simply  remove  from  NewS  all  added  actions,  i.e.  all  actions 
that  do  not  occur  in  OldActionNames.  The  result  is  formally  defined  by  function  Extract  (NewS) .  Note  that 
we  don’t  remove  any  read  or  write  actions,  because  R  and  W  belong  to  OldActionNames.  The  following  theorem 
expresses  that  Extract  (NewS)  is  accepted  by  OldProt. 

ExtractOld  ;  THEOREM  NewProt (NewS)  IMPLIES  OldProt (Extract (NewS) ) 

As  we  show  below,  the  proof  of  this  theorem  reveals  the  required  correctness  conditions.  Since  OldProt  is  conflict 
serializable,  theorem  ExtractOld  implies  Conf _ser_01d(Extract (NewS)). 

Step  2  If  Extract  (NewS)  is  conflict  serializability,  then  also  NewS; 

t 

ConfNewOld  :  THEOREM  Conf_ser_01d (Extract (NewS) )  IMPLIES 

Conf_ser_New(NewS) 

The  proof  of  this  theorem  uses  completeness  of  our  verification  method  for  conflict  serializability.  Since  it  implies 
Conf  _ser -New  (News) ,  this  completes  the  proof  of  theorem  MainTheorem.  End  Proof 

It  remains  to  prove  theorem  ExtractOld  and  to  derive  the  required  correctness  conditions. 

Proof  of  theorem  ExtractOld 

Assume  NewProt  (NewS) .  Then  there  exists  a  run  NewR  =  sq  ^  si  4  ...  Sn  ^  Sn+i  of  NewProt  such  that  NewS 
=  ActionSeq (NewR),  i.e.  NewS  =  aoai...a„.  Let  a^a'i-.a'^  be  the  sequence  obtained  from  aoOi...a„  by  removing 
all  actions  that  are  not  in  OldActionNames,  i.e..  Extract  (NewS)  = 

To  prove  OldProt  (Extract  (NewS)),  we  construct  a  run  Sq  ^  si  4  ...  s^,  4  of  OldProt.  This  run  is 
extracted  from  run  NewR  by  the  function  ExtractR  which  removes  from  a  run  of  NewProt  any  action  that  is  not 
in  OldActionNames  and  its  successor  state.  Moreover,  we  take  only  the  old  part  of  the  remaining  states.  Since 
Extract  and  ExtractR  both  remove  the  same  actions  (those  with  action  names  not  in  OldActionNames),  observe 
that  ActionSeq(ExtractR(NewR))  =  Extract  (ActionSeq  (NewR))  =  Extract  (NewS)  =  a'Qa\,..a!f,.  Hence,  it 
remains  to  prove  that  OldR  =  ExtractR  (NewR)  is  a  run  of  OldProt. 

For  any  run  r,  let  last(r)  denote  the  last  state  of  r.  Instead  of  proving,  that  ExtractR  (NewR)  is  a  run  in 
OldProt,  it  is  more  convenient  to  prove  the  following,  stronger  statement,  consisting  of  two  parts: 

(i)  ExtractR  (NewR)  is  a  run  of  OldProt  and 

(ii)  last (ExtractR (NewR))  =  old (last (NewR)). 

The  proof  proceeds  by  induction  on  the  length  of  ActionSeq  (NewR). 

Basic  Step  Let  length(ActionSeq(NewR))  =  0.  Then  NewR  =  NewInitState  and,  by  definition  of  ExtractR, 
ExtractR  (NewR)  =  old  (NewInitState).  Hence,  ExtractR  (NewR)  is  a  run  if  old  (NewInitState)  is  equal 
to  the  initial  state  of  OldProt.  Then  also  (ii)  is  satisfied.  This  leads  to  the  first  condition. 

Condition  1  old  (NewInitState)  =  OldInitState 
Induction  Step  Let  length(ActionSeq(NewR))  =  m  +  1.  Then  NewR  = 

NewRl-4last(NewR)  for  some  run  NewRl.  We  distinguish  two  cases. 

aci(o)  ^OldActionNames  Then  ExtractR  (NewR)  =  Extract  (NewRl).  For  part  (i),  recall  that  by  the 
induction  hypothesis  ExtractR(NewRl),  and  hence  also  ExtractR  (NewR) ,  is  a  run  of  OldProt. 

For  (ii),  note  that  last  (ExtractR  (NewR))  =  last  (ExtractR  (NewRl)) 

=  old  (last  (NewRl)),  using  the  induction  hypothesis.  To  obtain 
old  (last  (NewRl))  =  old  (last  (NewR)),  we  introduce  a  condition  expressing  that  if  we  apply  a  newly 
added  action  aa  to  an  extended  state  esl,  then  the  old  part  of  it  should  not  change. 

Condition  2 

NewEf feet (esl,  aa,  es2)  IMPLIES  old(esl)  =  old(es2) 
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act{a)  GOldActionNames  By  definition  of  ExtractR,  we  have  in  this  case 
ExtractR(NewR)  =  Extract  (NewRl)-^  old  (last  (NewR)). 

By  the  induction  hypothesis,  part  (ii),  we  have 
last  (Extract  (NewRD)  =  old(last(NewRl)), 

To  prove  (i),  note  that  ExtractR(NewR)  is  a  run  of  OldProt  if  the  following  two  conditions  are  satisfied. 

-  o  is  allowed  in  the  last  state  of  Extract  (NewRl) ,  that  is, 

OldPredast  (Extract (NewRl) )  ,  a)  =  TRUE. 

(  )■>  it  remains  to  prove  OldPre (old (last (NewRl)) ,  a)  =  TRUE.  Since  a  is  allowed  in  the  last 
state  of  NewRl,  we  have  that 

NewPre  (last  (NewRl) ,  o)  =  TRUE.  Hence  it  is  sufficient  to  require  that  any  old  action  oa  which  is 
allowed  in  an  extended  state  es  according  to  NowPre,  is  also  allowed  in  the  old(es)  accordine  to 
OldPre.  ■ 

Condition  3  NewPre  (es,  oa)  IMPLIES  OldPre  (old  (es)  ,  oa) 

-  old  ( last  (NewR))  is  obtained  from  last  (Extract  (NewRl))  by  applying  a  to  it,  i.e. 

OldEffect (last (Extract (NewRl)),  o.  old(last(MewR) ))  =  TRUE.  By  (*),  it  remains  to  prove 
01dEffect(old(last(NewRl)),  a, old (last (NewR)))  =  TRUE. 

Since  last  (NewR)  is  obtained  from  last  (NewRl)  by  applying  a  to  it,  we  have  NewEf  f  ect  (last  (NewRl) , 
a,  last  (NewR) )  =  TRUE.  Hence  it  is  sufficient  to  require,  for  any  old  action  oa,  that  NewEf  feet  must 
transform  the  old  part  of  an  extended  state  esl  in  the  same  way  OldEffect  does. 

Condition  4  NewEf  feet  (esl,  oa,  es2)  IMPLIES 
_ _ OldEffect  (old  (esl)  ,  oa,  old(es2)) 

This  proves  (i).  To  prove  (ii),  observe  that  by  the  definition  of  ExtractR.  in  this  case 
last  (ExtractR(NewR)  )=  olddast  (NewR)). 

This  completes  the  induction  step  and  also  the  proof  of  ExtractOld.  End  Proof 

To  implement  extensions  in  PVS,  we  define  a  general  PVS  theory  ProtExtend.  As  parameters,  it  has  all 
types  and  predicates  that  are  needed  to  define  OldProt  and  NewProt.  Theorem  MainTheorem,  which  establishes 
the  main  result,  is  proved  in  ProtExtend.  The  conditions  1  through  4  mentioned  above  are  added  to  this  theory 
by  including  them  as  four  assumptions.  If  any  theory  imports  ProtExtend  then  a  proof  of  these  assumptions  is 
required. 

^  Given  a  conflict  serializable  protocol  OldProt  we  can  prove  serializability  of  an  extension  NewProt,  by 
importing  theory  ProtExtend.  This  requires  a  proof  of  the  four  assumptions.  Once  they  have  been  proved’  we 
can  use  MainTheorem,  and  obtain  conflict  serializability  of  NewProt. 

6  Two  extensions  of  the  2PL  protocol 

We  have  applied  our  method  to  the  basic  2PL  protocol,  described  in  section  2.  This  protocol  is  extended  in  two 
steps,  leading  to  a  realistic  protocol  which  is  serializable  by  construction. 

First  extension  —  adding  a  sequence  of  waiting  transactions.  In  the  first  step,  we  associate  with 
each  data  item  a  sequence  of  transactions  that  are  waiting  for  the  permission  to  read  or  write  this  data  item. 

If  a  transaction  is  not  allowed  to  read  or  write  a  data  item  x  immediately  (because  it  is  currently  locked  in  an 
incompatible  mode),  the  corresponding  action  is  inserted  into  the  sequence  of  x.  After  x  becomes  available  a 
postponed  action  from  the  sequence  of  x  may  be  executed.  ’ 

The  operation  of  inserting  an  action  into  a  sequence  is  modeled  by  read-reguest  actions  (Rrequest)  and  a 
write-request  actions  (Wrequest).  The  extension  of  the  state  consists  of  a  function  that  maps  each  data  item 
to  a  finite  sequence,  consisting  of  read-  and  write-requests  performed  by  certain  transactions;  in  an  initial  state 
all  sequences  are  empty.  A  new  effect  predicate  transforms  the  state  in  the  same  way  Ef  f  ect2PL  does  for  old 
actions  it  leaves  the  old  part  of  the  state  unchanged  for  added  actions,  and  includes  an  additional  predicate  to 
defane  how  to  insert  and  remove  requests  from  the  waiting  sequences.  A  new  precondition  ensures  that  not  only 
preconditions  defined  by  Pre2PL  are  satisfied,  but  also  some  additional  preconditions. 

Second  step  —  adding  priorities  to  waiting  transactions.  We  define  a  second-level  extension  of  the 
2FL  protocol  by  extending  the  first-level  extension  above  such  that  the  processing  of  transactions  depends  on 
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their  priorities.  A  priority  function  PR  assigns  to  each  transaction  T  its  priority  PR(T)  from  the  set  of  natural 
numbers. 

We  also  introduce  the  notion  of  urgent  transactions,  which  is  important  for  real-time  protocols.  Assume  given 
a  natural  number  U.  Transaction  T  is  called  urgent  with  respect  to  U,  if  PR(T)  >=  U.  We  define  our  protocol  in  a 
new  theory,  such  that  its  set  of  parameters  includes  PR  and  U.  Changing  PR  and  U,  we  obtain  different  protocols. 
Therefore  our  theory  actually  defines  a  class  of  protocols. 

This  extension  does  not  introduce  any  new  control  information  or  any  new  actions.  Instead,  it  introduces 
some  restrictions  on  the  order,  in  which  transactions  are  performed.  The  aim  of  these  new  restrictions  is  to 
ensure  that  “urgent”  transactions  obtain  immediate  access  to  data  items,  whereas  that  non-urgent  transactions 
should  be  served  on  a  first-in,  first-out  basis. 

Suppose  a  data  item  x  has  a  sequence  xs.  We  define  a  predicate  urgent.exist,  which  expresses  that  xs 
includes  requests  from  urgent  transactions.  If 

urgent.exist(xs)  =  TRUE,  then  we  must  execute  one  of  the  urgent  transactions  with  the  highest  priority 
MaxPriority(xs).  Otherwise,  we  may  execute  the  first-inserted  request  of  the  waiting  sequence. 

Correctness  of  the  obtained  extensions.  After  importing  the  theory  ProtExtend  with  corresponding 
parameters  for  both  protocols,  it  turned  out  to  be  very  easy  to  prove  that  our  four  assumptions  are  satisfied  for 
both  protocols.  Therefore  our  extensions  indeed  ensure  conflict  serializability. 

Note  that  one  may  satisfy  the  conflict  serializability  condition  by  not  allowing  any  schedule.  Therefore,  we 
additionally  show  that  for  every  valid  schedule  in  the  initial  protocol  there  is  a  representative  in  the  extended 
protocol.  For  the  first  extension  of  the  2PL  protocol  presented  above,  it  is  easy  to  see  that  for  every  schedule  S 
in  the  2PL  protocol  there  is  a  representative  S’  in  the  extension,  which  consists  of  the  same  actions.  Let  S’  be 
a  schedule  where  a  transaction  never  tries  to  read  or  write  a  data  item  if  it  is  not  immediately  available;  then 
all  sequences  of  requests  are  always  empty  and  S  ’  is  indeed  accepted  by  the  extension.  The  same  holds  for  the 
second  extension  of  the  2PL  protocol. 

7  Concluding  remarks 

We  have  presented  a  formal  framework  for  the  specification  of  concurrency  control  protocols  and  the  verification 
of  serializability,  and  successfully  applied  it  to  the  verification  of  the  2PL  protocol  and  the  Timestamp  Ordering 
protocol.  Mechanical  support  has  been  obtained  by  formulating  this  framework  in  the  language  of  the  verification 
system  PVS,  and  all  proofs  have  been  constructed  by  means  of  the  interactive  theorem  prover  of  PVS. 

Moreover,  a  systematic  way  to  extend  serializable  concurrency  control  protocols  has  been  developed.  If  such 
an  extension  satisfies  four  simple  verification  conditions,  it  is  serializable  by  construction.  This  can  be  applied  in 
a  hierarchical  way,  thus  complex  protocols  can  be  obtained  by  a  sequence  of  extensions  of  a  basic  concurrency 
control  protocol.  An  old,  serializable,  protocol  can  be  extended  to  a  new  protocol  by  adding  more  control 
information  to  the  state  and  introducing  additional  control  actions.  One  has  to  define  the  new  initial  state,  a 
new  precondition  for  all  actions  and  a  new  effect  predicate  which  describes  the  state  change  after  eaeh  action. 
Then  the  new  protocol  is  serializable  if  the  following  conditions  are  satisfied. 

1.  Ignoring  the  added  control  part,  the  new  initial  state  equals  the  old  initial  state. 

2.  A  new  action  only  affects  the  added  part  of  the  state;  it  does  not  change  the  original  part  of  the  state. 

3.  The  new  precondition  of  an  old  action  implies  its  old  precondition. 

4.  The  new  effect  of  an  old  action  implies  its  old  effect. 

There  are  several  directions  for  future  work.  We  intend  to  investigate  more  protocols  and  develop  more 
detailed  strategies  for  their  verification.  We  may  also  add  timing,  i.e.  extend  our  method  to  real-time  database 
protocols.  Another  possibility  is  to  study  not  only  serializability  for  databases,  but  also  more  general  protocols 
and  correctness  notions  such  as  atomicity  of  transactions. 
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Abstract.  This  paper  presents  the  platform  independent  approach  to  detecting  shared  memory  paral¬ 
lelism.  The  brief  overview  of  Automatic  Parallelizing  Expert  Toolkit  being  developed  and  the  description 
of  basic  concepts  used  by  this  toolkit  are  given. 

1  Introduction. 

Known  approaches  to  porting  existing  serial  programs  onto  parallel  platforms  could  be  divided  into  two  groups: 

-  using  of  automatically  parallelizing  compilers  [1,2]; 

-  adding  to  the  source  codes  of  serial  program  special  directives,  which  explicitly  specify  the  actions  to  be 
taken  by  the  compiler  and  run-time  system  in  order  to  execute  the  program  in  parallel. 

Both  of  these  approaches  have  some  shortcomings. 

Parallelizing  compilers  usually  does  not  detect  all  the  regions  where  parallelization  is  possible.  Moreover, 
it  could  be  uneasy  task  to  determine  rather  compiler  detect  the  parallelism  or  not,  and  why.  Adding  new 
parallelizing  techniques  to  such  compilers  is  upiio  vendor,  so  developer  cannot  rely  on  soon  release  of  techniques 
needed.  This  approach  also  led  to  portability  problems  —  different  compilers  can  be  significantly  different  in 
parallelization  quality. 

Explicit  specification  of  all  the  necessary  parallel  regions  may  be  even  more  complex  task.  Though  the  result¬ 
ing  program  would  probably  work  better  this  is  not  the  case  of  program  reuse  —  this  approach  is  comparable 
to  writing  completely  new  code. 

The  way  out  from  such  situation  could  be  found  in  using  restructuring  tools  that  automatically  inserts 
parallelization  directives  into  ordinary  serial  source  code;  the  possibility  of  adding  new  parallelization  techniques 
by  tool’s  user  should  be  present. 

This  approach  has  the  following  obvious  advantages: 

-  the  output  of  such  tool  is  a  meaningful  source  code  thus  developer  understand  clearly  what  parallelization 
has  made; 

-  appearance  of  such  directive  sets  as  OpenMP  API  [3]  solves  a  problem  olf  cross-platform  portability  within 
a  class  of  SMP  platforms; 

-  the  tool  based  on  expert  systems  technology  can  explain  all  the  parallelizing  actions  made; 

-  once  an  existing  set  of  techniques  does  not  satisfy  a  particular  developer  it  is  possible  to  expand  this  set 
with  new  ones. 

It  is  clear  that  such  tool  needs  powerful  models  of  both  the  ’’parallel  program”  and  the  ’’parallelization 
technique” .  This  paper  presents  these  models  targeted  on  implementation  of  Automatic  Parallelizing  Expert 
Toolkit  (APET)  and  provides  toolkit  architecture  overview. 


2  Parallel  Program  and  Execution  Models. 

APET  utilizes  two  models  (the  single  at  the  same  time)  of  parallel  program: 

-  Extension  of  Model  of  Structured  Program  (MSP  [4]),  called  Model  of  Parallel  Program  (MPP  [5]).  This 
model  represents  a  parallel  program  in  n-processor  SMP-systera  as  n  serial  programs  with  common  data 
space  and  additional  synchronization  points,  so-called  barriers. 
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—  Open-MP  compliant  Fork-Join  Model,  FJM.  In  this  model  program  begins  execution  as  a  single  thread  of 
execution  called  master  thread.  The  master  thread  executes  as  a  serial  region  until  the  parallel  construct 
creates  a  team  of  threads,  which  executes  in  parallel.  Upon  completion  of  parallel  construct,  the  threads  in 
the  team  synchronize  at  an  implicit  barrier,  and  only  the  master  thread  continues  execution.  Work  sharing 
directives,  nested  peirallelism  and  orphaning  is  permitted. 

It  is  shown  that  for  a  great  enough  n  the  conformity  between  these  models  exists.  The  MPP  is  quite  a  simple 
model  to  operate,  but  APET’s  output  in  this  model  can  be  used  only  as  an  illustration  of  toolkit’s  actions. 
On  the  contrary,  the  FJM  is  much  more  complex;  APET’s  output  using  this  model  can  be  interpreted  as  C  or 
FORTRAN  program  with  Open  MP  compliant  extensions  and  than  immediately  be  compiled  under  the  most 
of  the  popular  SMP-platforms. 


3  Parallelizing  technique  model. 

Parallelizing  technique  in  APET  is  represented  in  three  parts: 

—  Condition  logical  expression  in  terms  of  MPP  or  FJM.  The  Parallelizing  technique  is  possible  to  apply 
if  and  only  if  this  condition  is  true. 

Subset  of  variables  defined  in  Condition.  These  variables  are  the  parts  of  the  program,  which  will  change 
due  to  the  given  technique,  so-called  ’’Parallelization  Region”.  Note  that  the  value  of  these  variables  is  one 
or  more  consequent  operators  and/or  directives. 

-  Parallelizing  Transformation  —  the  set  of  expressions  determining  the  new  value  of ’’Parallelization  Region”. 

4  Automatic  Parallelizing  Expert  Toolkit  architecture  overview. 

APET’s  input  is  a  model  of  serial  program  (MSP)  obtained  by  specialized  compiler  from  high-level  languages 
and  the  knowledge  base  of  parallelization  techniques.  The  output  is  MPP  or  FJM  model  that  represents  the 
source  program  after  all  the  parallelization  techniques  possible  applied.  Both  of  the  models  can  be  converted 
back  into  the  high-level  language  (not  necessary  the  same  as  the  source)  form.  APET  also  provides  an  extensive 
report  explaining  which  of  the  parallelization  techniques  were  (or  were  not)  applied  and  why  (see  figure  1). 

It  is  also  possible  to  define  the  set  of  criteria  of  pai-allelization  quality  to  measure  some  static  values  of 
parallelization  made  by  selected  set  of  parallelization  techniques. 

References 

1.  William  Blume,  Ramon  Doallo,  Rudolf  Eigenmann  et  al.  Advanced  Program  Restructuring  for  High-Performance 
Computers  with  Polaris.  Technical  report  1473.  University  of  Illinois  at  Urbana-Champaign,  Center  for  Supercom¬ 
puting  Res.  &;  Dev.  January  1996. 

2.  Briang  Armstrong,  Seon  Wook  Kim,  Insung  Park,  Michael  Voss  and  Rudolf  Eigenmann.  Compiler-Based  Tools  for 
Analyzing  Parallel  Programs.  Parallel  Computing  Journal,  1997. 

3.  Open  MP  C  and  C++  Application  Program  Interface.  Document  No.  004-2229-001.  October  1998;  Open  MP  Archi¬ 
tecture  Review  Board,  http://www.openmp.org.  ’ 

4.  Oleg  A.  Kupnevich,  Margarita  A.  Knyazeva.  Expert  Toolkit  for  Simulating  Program  Optimization.  Preprint.  Institute 
for  Automation,  Vladivostok,  1997. 

5.  Yury  y.  Chelomin.  Model  of  optimization  process  for  shared  memory  parallel  programs.  Proceedings  of  E  Zolotov’s 
workshop.  Vladivostok,  June  1998.  (In  Russian) 


Chelomin  Y.  V.  Platform  Independent  Approach  for  Detecting  Shared  Memory  Parallelism 


135 
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Abstract.  We  suggested  an  extension  of  the  class  of  cause-effect  structures  by  semantics  of  hierarchy.  As 
an  example  of  hierarchical  c-e  structure  we  use  a  simulation  of  zero-testing  operator.  Relationships  between 
classes  of  hierarchical  c-e  structures  and  hierarchical  Petri  Nets  introduced  by  V.E.  Kotov  are  investigated. 


1  Introduction 

In  order  to  describe  concurrent  systems,  L.Czaja  has  introduced  in  [1]  cause-effect  structures  (CESs)  which 
were  inspired  by  condition/event  Petri  nets  (PNs).  CES  can  be  defined  as  a  triple  {X,C,E)  where  X  is  the 
set  of  nodes,  C  and  E  are  the  cause  and  effect  functions  from  X  to  the  set  of  formal  polynomials  over  X  such 
that  X  €  X  occurs  m  C(7/)  iff  p  occurs  in  E(x).  Each  polynomial  C(x)(E(x))  denotes  a  family  of  cause  (effect) 
subsets  of  the  node  x.  The  operator  *  combines  nodes  into  subsets,  and  the  operator  -I-  combines  subsets  into 
families. 

.  Unfortunately,  practical  expressiveness  of  CESs  is  not  sufficient  to  use  them  in  real-life  applications.  Some 
supplementary  constructions,  for  instance,  semantics  of  coloured  tokens  or  hierarchy  are  necessary. 

Note  that  the  extension  of  CESs  by  coloured  tokens  has  been  received  in  [7].  In  ordinary  CESs  a  token  or 
an  active  state  of  a  node  denotes  presence  of  some  resource.  However  this  approach  does  not  allow  qualitative 
difference  between  resources  functioning  in  CES  to  be  discovered.  Moreover,  each  node  should  not  simultaneuosly 
have  more  than  one  token-resource.  Sometimes  it  is  important  to  differ  resource  qualitatively.  This  difference  is 
represented  by  colours  of  tokens,  and  each  node  may  have  several  differently  coloured  tokens. 

This  work  is  devoted  to  constructing  a  class  of  hierarchical  CESs  (HCESs)  which  improves  compactness  of 
the  algebraic  representation  of  CESs  and  enlarges  their  practical  expressiveness. 

Relationships  between  this  new  class  and  the  class  of  hierarchical  Petri  nets  (HPNs)  introduced  by  V.E.Kotov 
in  [3]  are  investigated.  We  prove  that  every  HCES  has  behaviorally  equivalent  HPN, 

There  was  an  interesting  open  problem;  in  [4]  Raczunas  investigates  converse  mapping  from  PNs  to  CESs. 

•  called  strong  equivalence  is  not  the  case  for  converse  mapping.  We  decided  this  problem 

m  [6]  by  introducing  extension  of  caus^effect  structures  -  two-level  CESs  (TCESs).  TCESs  is  a  convenient 
mtermediate  class  between  PNs  and  CESs,  because  it  is  strongly  equivalent  to  the  class  of  PNs  and  we  can 
toansform  JCES  into  structurally  equivalent  CES  with  the  help  of  folding-transformation.  On  the  other 
hand,  each  CES  has  a  strongly  equivalent  TCES. 

the  converse  mapping  from  HPNs  to  HCESs  is  decided  with  help  of  the  class  of  two-lewel 

HCEos. 


2  Preliminaries 

2.1  Regular  and  Hierarchycal  Petri  Nets  ' 

The  algebra  of  regular  Petri  nets  (RPN)  introduced  in  [2]  is  generated  by  the  class  of  atomic  nets  with  the  use 
ot  the  set  of  net  operations. 

An  atomic  net  is  a  net  of  the  following  form: 


where  is  a  transition  symbol,  is  a  head  net  place,  “  is  its  tail  place. 
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The  concurrency  operation  (denoted  by  is  defined  as  a  common  graph  union:  it  superposes  one  net  on 
another. 

IfNi  =  (Pi.Ti.Fi)  and  N2  =  (P2,72,-p2)  then 
N  =  (Ni,N2)  =  (Pi  U P2,Ti  U T2,Fi  U P2) 

Let  h{N)  denote  the  set  of  head  places  of  a  net  N  and  1(N)  be  the  set  of  tail  places  of  N.  By  definition, 
h{N)  =  h{Ni)Uh{N2)  &ndl{N)  =  liNi)UliN2). 

Other  net  operations  can  be  defined  via  the  concurrency  operation  and  an  auxiliary  merging  operation.  The 
latter  merges  two  sets  of  places  in  a  specific  way.  This  involves  two  suboperations:  1)  formation  of  a  set  of 
merged  places,  2)  replacement  of  two  existing  sets  by  a  new  set. 

Given  two  sets  of  places  X  and  Y  the  forming  operation  x  results  in  the  set  Z  of  merged  places: 

Z  =  XxY  =  {xUy\x€X,yeY} 

The  merqinq  operation  M  merges  tv/o  sets  of  places,  X  and  Y,  in  a  net  N  —  (P,  T,  F)  and  generates  a  new 
net  M(iV,X  X  F)  =  (P',r',P'),  where 

P'  =  P-{XUY)U{X  xY),T'  =-T, 

^p£XxY:  F'ip)  =  Fix)  U  Fiy), 
where p=:  xUy. 

The  operation  of  iteration  ”  *”  merges  the  sets  of  head  and  tail  places  of  the  net  if  their  intersection  is  empty: 

N'  =  *iN)  =  miN,  h{N)  x  1(7V)) 

By  definition,  its  sets  of  head  and  tail  places  are  equal. 

The  precedence  operation  joins  two  nets  by  merging  the  set  of  tail  places  of  the  first  net  with  the  set  of 
head  places  of  the  second  net.  By  definition,  fi.(iV’)  =  h(iV’i)  and /(A^)  =  l(Ar2). 

The  alternative  operation  ”  V”  unites  two  nets  by  merging  their  sets  of  head  places  and  their  sets  of  tail 
places  separately.  By  definition,  h{N)  =  hiNi)  x  h{N2)  and  liN)  —  f(A^i)  x  1{N2)- 

Let  P  be  a  class  of  atomic  nets,  i.e.  a  class  of  transition  symbols.  A  net  formula  in  the  algebra  of  RPN  over 
basis  E  is  defined  as  follows: 

1)  each  symbol  of  P  is  a  formula; 

2)  if  A  is  a  formula,  then  *(A)  is  a  formula; 

3)  if  A  and  B  are  formulae,  then  (A,  P),  {A\B)  and  (AVP)  are  formulae. 


The  class  of  hierarchical  Petri  nets  (HPN)  introduced  in  [3]  is  a  generalization  of  the  class  of  RPN  and  is 
used  for  modelling  hierarchical  systems. 

To  define  HPN,  we  should  divide  the  class  of  transition  symbols  into  two  nonintersecting  subclasses:  terminal 
and  nonterminal  symbols.  Correspondingly,  any  transition  can  be  simple  or  compound. 

HPN  is  defined  by  a  structural  formula  constructed  from  terminal  and  nonterminal  symbols  using  the  set  of 
the  (regular)  net  operations  and  an  ordered  set  of  nonterminal  symbols’  definitions. 

Each  such  definition  looks  like  s  :  A,  where  s  is  a  nonterminal  symbol,  and  A  is  a  formula  of  HPN  which  is 
internal  for  this  symbol. 

We  have  two  contextual  restrictions: 

1)  Any  symbol  of  a  structural  formula  is  terminal  if  it  is  not  defined  in  this  formula. 

2)  Each  nonterminal  symbol  is  defined  only  once  and  it  can  not  join  the  right-hand  part  of  its  definition  and  all 
the  following  ones. 

A  compound  transition  may  be  in  a  passive  or  active  (when  its  internal  net  is  working)  state.  The  begining 
and  the  end  of  a  compound  transition’s  work  are  momentary  events. 

On  Fig.l  you  can  see  HPN  which  allows  us  to  check  whether  the  place  x  has  token.  Thus,  expressive  power 
of  the  class  of  HPNs  is  greater  than  of  the  class  of  PNs. 
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2.2  Cause-Effect  Structures 

Cause-effect  structures  are  represented  as  directed  graphs  with  an  additional  structure  imposed  on  the  set 
of  nodes.  These  graphs,  with  operations  -b  and  *  corresponding  to  nondeterministic  choice  and  parallelism, 
constitute  a  near-semi-ring  where  ’’near”  means  that  distributivity  of  *  over  +  holds  conditionally. 

A  CES  is  completely  represented  by  the  set  of  annotated  nodes:  each  node  x  is  subscribed  by  a  formal 
polynomial  E{x)  built  of  (names  of)  its  successors  and  superscribed  by  a  formal  polynomial  C{x)  built  of  its 
predecessors  and  may  be  either  in  an  active  or  passive  state.  The  active  state  of  a  node  represents  the  presence 
of  control  in  it. 

If  a  node  is  active,  then  we  try  to  move  control  from  it  simultaneously  to  all  its  successors  which  form  a 
product  in  its  lower  (subscript)  polynomial  -  if  they  are  passive.  Symmetrically,  if  a  node  is  passive,  then  we  try 
to  move  control  to  it  simultaneously  from  all  its  predecessors  which  form  a  product  of  its  upper  (superscript) 
polynomial  -  if  they  are  active  (if  no  predecessors  or  successors  exist  then  the  upper  or  lower  polynomial  is  6 
omitted  sometimes).  This  rule  renders  complex  -  in  general  -  interdependences  between  nodes  in  the  aspect  of 
a  control  flow:  a  group  of  nodes  have  to  ’’negotiate”  the  possibility  of  changing  their  state  with  one  another. 
Such  groups  of  nodes  will  play  a  role  similar  to  that  of  transitions  in  PNs.  They  are  called  firing  components. 
The  set  of  all  firing  components  of  the  CES  U  is  denoted  by  FC[U]. 

All  the  formal  definitions  of  CESs  can  be  found  in  [1].  Moreover,  for  better  understanding  and  convenience 
of  comparison,  we  include  all  these  definitions  to  Sect.3:  Definitions  3.1,  3.2,  3.3,  3.6,  3.7,  3.8  and  3.10  without 
any  changes;  Definition  3.5  modifed  a  little  for  the  case  of  hierarchy,  and  Definition  3.12  with  additional  (second 
and  third)  alternative  groups  of  conditions. 


3  Hierarchical  Cause-Effect  Structures 

We  construct  an  extension  of  the  CESs  class  up  to  hierarchical  one  in  the  manner  proposed  by  V.E.Kotov  for 
P^ri  nets.  We  have  compound  transitions  in  the  hierarchical  Petri  nets  (HPNs),  but  CESs  have  only  one  type 
of  vertices  -  nodes.  The  attempt  to  introduce  compound  nodes  leads  to  complicated  and  unwieldy  construction. 

Our  solution  is  to  introduce  compound  or  ”  global”  tokens  which  appear  on  some  directions  of  moving  control 
between  nodes.  Each  such  token  includes  an  inner  CES.  When  a  group  of  nodes  is  ready  to  move  control  jointly 
to  their  successors  and  at  least  one  of  them  gives  birth  to  a  global  token  on  this  direction,  then: 

-  this  group  of  nodes  move  control  to  CES  which  is  inner  for  appearing  global  token; 

-  the  inner  CES  is  working  and  when  it  reaches  the  final  state  it  moves  control  to  all  successors  of  the  original 

group  of  nodes.  ^ 
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In  fact  we  have  some  subclass  of  hierarchycal  or  global  firing  components.  This  way  allows  us  to  preserve 
the  style  and  the  scheme  of  defining  CESs.  We  add  only  a  globalization  function  on  the  set  of  nodes,  and  extend 
semantics  correspondingly. 

Definition  1.  (S-1.)  Let  X  be  a  set  called  a  space  of  nodes  and  let  $  be  a  symbol  called  neutral.  The  least  set 
Y  satisfying  the  following:  CY,ifK  6  Y  and  L  e  Y  then  {K  +  L)  €  Y  and  (K  *  L)  G  Y,  is  a  set  of 

polynomials  over  X  denoted  by  FIX]. 

Definition  2.  (3.2.)  We  say  that  the  algebraic  system  A  =  (E'[X], +,  *,0)  is  a  near-semi-ring  of  polynomials 
over  X  if  the  following  axioms  hold  for  all  K  G  F[X],L  G  F[X],M  G  F[X],x  G  X  : 

(-t)  9  +  K-=K  +  e-=K  (*)  e*K  =  K*9  =  K 

(++)  K  +  K^K  (**)  x*x^x 

(-I-+-I-)  K-{-L  =  L-^K  (***)  K*L  =  L*K 

(-l-f-+-l-)  K  +  {L-\-M)^iK-i-L)  +  M  {****)  K*iL*M)  =  {K*L)*M 

(+*)  K*{L  +  M)  =  K*L-^-K*M 

provided  that  either  L  =  M  =  6  or  L  ^  9  and  M  ^  9 

Definition  3.  (3.3.)  Let  X  be  a  space  of  nodes  and  (F[X],+,*,0)  be  a  near-semi-ring  of  polynomials.  A  CES 
over  X  is  a  pair  (C,E)  of  functions: 

C  :  X  — >  F[X]  (cause  function) 

E  :  X — >  F[X]  (effect  function) 

such  that  X  occurs  in  the  polynomial  C{y)  iffy  occurs  in  E{x)  (then  x  is  a  cause  of  y  and  y  is  an  effect  of  x). 
The  set  of  all  CES's  over  X  is  denoted  by  CE[X]. 

The  CES  is  completely  represented  by  the  set  of  annotated  nodes  x. 

Definition  4.  (3.4.)  Let  {C,E)  is  a  CES  overX,  and  let  for  each  x  e  X  its  effect  polynomial  be  transformed  to 
the  canonical  form:  E(x)  =  Y)Ei{x),  where  each  Ei{x)  is  a  monomial.  The  globalization  function  G  prescribes 
some  global  token  (i.e.  a  token  which  includes  an  inner  CES  or  the  neutral  element  9)  to  each  effect  direction 
Ei{x)  of  each  node  x.  Then  a  hierarchical  cause-effect  structure  is  a  triple  of  functions  {C{X),E{X),G{< 
X,EiX)»). 

The  set  of  all  HCESs  over  is  denoted  by  HW. 

Remark  1.  A  token  may  be  an  ordinary  ’’unfaced”  resource  denoted  by  9.  That  is,  if  G{<  x,Ei(x)  >)  —  9  for 
some  node  x  and  direction  Ei{x),  then  it  means  that  the  token  on  this  direction  is  non-compound,  and  moving 
of  control  runs  without  delay. 

Definition  5.  (3.5.)  Let  us  define  the  addition  and  multiplication  of  functions  by  the  rules: 

(Cl -i- C2)ix)  =  Ci{x) +  C2{x)  and  {El  +  E2){x)  -  Ei{x)  +  E2{x), 

G{<x,Ei>)  =  Gi{<x,Ei>y, 

{Cl  *  C2){x)  =  Ci{x)  *  C2{x)  and  {Ei  *  E2){x)  =  Ei{x)  *  E2{x), 

G{<  x,Ei  *  E2  >)  =  Gi{<  x,Ei  >) -^  G2{<  x,E2  >)■ 

Then  an  algebra  of  HCESs  is  obtained  as  follows.  Let  9  :  X  — >  F[X]  be  a  constant  function  9{x)  =  9,  let,  for 
brevity,  the  HCES  {9, 9)  be  denoted  by  9,  and  let  +  and  *  on  HCESs  be  defined  by  the  following: 

{i,i,Gi) {2,2,G2)  =  {i  +  2,1  +  z^G), 

(1,  IjGl)  *  {2,2,G2).=  (1  *  2)  1  *  2)  f?)- 

Obviously,  if  Ui  =  {Ci, Ei,Gi)  G  HCE[X]{i  =  1,2),  then  Fi  -f  1/2  G  HCE[X]  and  t/i  *  1/2  G  HCE[X]. 

Definition  6.  (3.6.)  A  CES  U  is  decomposable  iff  there  exist  CESs  V,W  such  that 
9^V-^U,9^W^U  and  either  U  =  V  -\-W  orU  =  V*  W . 

Definition  7.  (3.7.)  Let  U,  V  be  CESs.  V  is  a  substructure  of  U  iff  V  ■+■  U  =  U.  Then  we  write  V  <  U. 
SUB[U]  —  {V  :  V  <  U}.  Easy  checking  ensures  that  <  is  a  partial  order.  The  set  of  all  minimal  (wrt  <)  and 
^  9  elements  of  SUB[U]  is  denoted  by  MINfU]. 

Definition  8.  (3.8.)  For  a  CES  U,  let  Q  =  {Cq,Eq)  he  a  minimal  substructure  of  U  such  that  for  every  node 
X  in  Q: 

(i)  polynomials  Cq{x),Eq{x)  do  not  comprise 

(a)  exactly  one  polynomial,  either  Cq{x)  or  Eq{x),  is  9. 

Then  Q  is  called  a  firing  component  of  U.  FC^[U]  =  {Q  €  MIN[U]  :  {i),{ii)  hold}  is  the  set  of  all  firing 
components  of  the  first  level.  We  denote  by  *Q  (pre-set  of  Q)  the  set  of  nodes  x  in  Q  with  Cq{x)  =  9,  and  by 
Q*  (post-set  of  Q)  the  set  of  nodes  x  in  Q  with  Eq{x)  =  9. 
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Remark  2.  Each  internal  CES  has  a  set  of  its  own  firing  components.  Thus,  there  exist  a  union  of  sets  of  firing 
compoMnts  over  all  internal  CESs  of  the  first  level  called  a  set  of  firing  components  of  the  second  level,  and 

so  on.  The  full  se  of  firing  components  of  any  HCES  [7  (denoted  by  FC[U])  is  a  union  of  its  sets  of  firing 
components  or  all  levels.  ^ 

Definition  10.  (3.10.)  A  state  is  a  subset  of  the  space  of  nodes  X.  A  node  x  is  active  in  the  state  s  iff  x  e  s 
and  passive  otherwise.  jj  ^ 

Definition  11.  (S  II.)  Ut  na  define,  for  each  global  firing  component  Q,  two  tupplementary  anbsets  of  its 

htijGm  ' 

Definition  13.  (S.I2.)  Fop  Q  e  FC[U],  let  [(0])  denote  o  binary  relation  on  the  set  of  all  states:  (s,t)  e  [[«]] 

*QQs,  G{Q)=e,  QT\s  =  0,  t={s-*Q)uQ* 

or 

G(Q)jtte,  So{G{Q))ns  =  0,  t  =  is-*Q)uSoiG(Q)) 

or 

Send{G{Q))  Cs,  Q•(^s  =  0,  t  =  {s-  Send{G{Q)))  U  Q* .  ’ 

Semantics  [[f/]]  of  a  HCES  U  is  a  union  of  relations: 

[[^]]  -  U  [[Q]] 

QSFCIU] 

Remark  3.  Firstly,  in  preserving  the  condition  Q*  n  s  =  0  and  similar,  we  follow  the  tradition  of  defining 
semantics  of  CESs  that  requires  the  artificial  safety.  That  is,  each  node  must  not  have  more  than  one  token 
Secondly,  alternative  groups  of  conditions  in  Def.3.12  mean  the  following; 

- 1  the  firing  component  is  not  global,  all  nodes  of  its  pre-set  are  active  and  all  nodes  of  its  post-set  are  passive 
‘  rr  from  all  nodes  of  its  pre-set  to  all  nodi  0?^  ^? 

in trS  Hc”lirrsf  'f  0'  initial  sfateot  its 

Inodes  fern  rS  iite!  “CES.-firlng" 

i  iit"?  e  component  has  reached  the  terminal  state  and  all  nodes  of  the  post-set 

of  this  global  firing  component  are  passive,  then  control  is  moving  to  them.  ■ 


On  Fig.2  one  can  see  a  HCES  which  is  equivalent  in  a  sense  to  HPN  on  Fig.l: 
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4  Relationships  between  HCESs  and  HPNs 

There  is  an  interesting  question  about  relationships  between  GESs  and  PNs.  In  [4]  Raczunas  states  that  every 
CES  has  a  strongly  equivalent  PN,  i.e.,  two  bijections  exist:  between  the  firing  components  of  CES  and  transitions 
of  PN,  and  between  nodes  of  CES  and  places  of  PN;  moreover,  the  bijections  must  preserve  pre-  and  post-sets 
of  firing  components  and  transitions. 

In  [2]  Kotov  proved  that  each  PN  has  a  behaviorally  equivalent  regular  PN,i.e.,  their  sets  of  languages  or 
traces  of  firing  are  equal.  So  we  may  formulate; 

Theorem  1.  (1.)  Each  HCES  has  a  behaviorally  equivalent  HPN. 

Sketch  of  a  proof.  In  [4]  Raczunas  proves  that  each  CES  has  strongly  equivalent  PN.  But  the  only  structural 
difference  between  CES  and  HCES  is  the  globalization  function  which  does  not  touch  an  external  cover  of 
HCES  (the  cover  is  a  HCES  in  which  all  global  firing  components  are  substituted  by  simple  ones).  The  last  is 
an  ordinary  CES  and  so  it  has  a  strongly  equivalent  PN  which  is  the  cover  of  some  HPN.  But  the  cover  of  an 
internal  HCES  of  any  global  firing  component  also  is  a  CES  and  has  a  strongly  equivalent  PN  which  is  internal 
for  corresponding  global  transition  of  this  cover-HPN,  and  so  on.  Finally,  with  the  help  of  the  regularization 
algorithm  (see  [2]),  we  construct  a  behaviorally  equivalent  HPN  from  given  set  of  strongly  equivalent  external 
and  internal  PNs. 

Raczunas  investigates  a  converse  mapping  from  PNs  to  CESs.  He  remarks  that  strong  equivalence  is  not  the 
case  for  the  converse  mapping. 

We  decided  this  problem  in  [6]  by  introducing  an  extension  of  cause-effect  structures  -  two-level  CESs 
(TCESs).  Any  CES  is  completely  represented  by  the  set  of  annotated  nodes  where  E(x)  and  C(x)  are 

polynomials  with  operations  -f  and  *.  We  propose  to  exclude  the  operation  +  from  the  formal  polynomials  and 
to  call  the  resulting  elementary  CES  (or  unalternative  CES  -  UCES)  a  two-level  CES  of  the  first  syntactic  level. 
Elementary  CESs  are  united  by  the  operation  0  into  the  set  called  a  two-level  CES  of  the  second  syntactic 
level,  or  simply  TCES.  Thus,  TCES  is  a  set  of  sets  of  annotated  nodes. 

So,  the  operation  ©  is  a  union  of  sets  of  an  upper  level.  It  differs  from  the  operation  -I-  because  it  does 
not  merge  elementary  CESs  into  a  set  of  annotated  nodes.  An  operation  ®  on  the  set  of  TCESs  is  a  Cartesian 
product  of  sets  of  an  upper  level.  The -operation  ®  on  the  set  of  UCESs  is  the  same  as  operation  *  on  the  set 
of  CESs.  In  its  canonical  form  TCES  is  a  sum  of  its  firing  components. 

TCESs  is  an  usefull  intermediate  class  betwc  '-n  PNs  and  CESs,  because  it  is  strongly  equivalent  to  the  class  of 
PNs  and  we  can  transform  any  TCES  into  structurally  equivalent  CES  with  the  help  of  folding-transformation. 
On  the  other  hand,  each  CES  has  a  strongly  equivalent  TCES.  Thus,  there  are  only  structural  differences 
between  TCESs  and  CESs,  their  semantics  are  the  same.  So  the  semantics  of  hierarchy  is  transferred  to  the 
class  of  TCES  without  essential  changes.  Thus,  we  have: 

Theorem  2.  (2.)  Each  HPN  has  a  strongly  equivalent  hierarchical  TCES. 

Sketch  of  a  proof.  An  algorithm  of  constructing  of  a  strongly  equivalent  HCES  is  stage  by  stage: 

1.  we  map  the  cover-net  of  given  HPN  in  a  strongly  equivalent  CES  which  is  the  cover-structure  of  the  con¬ 
structed  HCES; 

2.  we  map  the  cover-net  of  an  internal  HPN  of  each  compound  transition  of  the  first  level  in  a  strongly  equivalent 
CES  which  is  the  cover-structure  of  an  internal  HCES  of  corresponding  global  firing  component; 

3.  and  so  on. 

On  the  each  stage  we  deal  with  mapping  an  ordinary  PN  in  ordinary  CES.  But  the  algorithm  of  such  mapping 
has  constructed  and  proof  of  its  correctness  and  fullness  has  made  in  [6]. 


5  Conclusion 

This  work  is  a  continuation  of  the  series  of  papers  [5],  [6],  [7]  devoted  to  constructing  different  extensions  and 
generalization  of  the  cause-effect  structures.  Moreover,  the  globalization  function  proposed  in  this  work  has 
more  general  and  important  meaning.  It  allows  us  to  unite  all  these  extensions  into  an  universal  model.  That 
is,  such  function  may  prescribe  internal  CESs  to  one  group  of  firing  components,  time  restrictions  to  another 
one,  and  rules  of  token  colour  transformations  to  some  other  firing  components.  Thus,  an  important  direction 
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of  future  investigations  is  constracting  a  high-level  class  of  CESs  which  will  unite  feasibilities  and  advantages  of 
all  above  semantics  and  two-level  representation. 
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Abstract.  Nested  Petri  nets  are  Petri  nets  using  other  Petri  nets  as  tokens.  Their  nested  structure  make 
some  important  verification  problems  undecidable  (reachability,  boundedness,  . . . )  while  some  other  prob¬ 
lems  remain  decidable  (termination,  inevitability,  . . . ). 


1  Introduction 

For  modelling  and  analysis  distributed  concurrent  systems,  there  exists  a  large  variety  of  formalisms  based  on 
Petri  nets  [Rei85,Smi96,Jen92,Lom97].  Among  them,  several  approaches  extend  the  Petri  nets  formalism  by 
notions  and  structures  inspired  from  object  oriented  programming  [Sib94,Lak95,MW97,Val98].  Such  extensions 
are  helpful  for  modelling  hierarchical  multi-agent  distributed  systems. 

While  Sibertin-Blanc  [Sib94],  Lakos  [Lak95],  Moldt  and  Wienberg  [MW97]  consider  systems  with  communi¬ 
cating  coloured  Petri  nets,  Valk  [Val98]  in  his  object  Petri  nets  considers  tokens  as  objects  with  a  net  structure. 
In  his  approach,  the  system  net  and  object  nets  are  elementary  net  systems,  but  an  object  is  in  some  sense  not 
located  in  one  place  (since  Valk  uses  object  Petri  nets  for  solving  specific  fork-join  situations  in  task  planning 
systems),  and  this  leads  to  a  rather  complex  definition  of  the  notion  of  states  for  object  Petri  nets. 

Nested  Petri  nets.  Here  we  study  another  Petri  net  model  where  tokens  may  be  nets  themselves:  nested  ^  Petri 
nets  [Lom98].  Nested  Petri  nets  are  a  convenient  tool  for  modelling  hierarchical  multi-agent  dynamic  systems. 
The  object  nets  in  a  nested  Petri  net  have  their  own  structure  and  behaviour,  they  may  evolve  and  disappear 
during  the  system  lifetime,  and  their  number  is  unlimited.  A  nested  Petri  net  has  four  kinds  of  steps.  A  transfer 
step  is  a  step  in  a  system  net,  which  can  “move”,  “generate”,  or  “remove”  objects,  but  does  not  change  their 
inner  states.  An  object-autonomous  step  changes  only  an  inner  state  in  one  object.  There  are  also  two  kinds  of 
synchronisation  steps.  Horizontal  synchronisation  means  simultaneous  firing  of  two  object  nets,  situated  in  the 
same  place  of  a  system  net.  Vertical  synchronisation  means  simultaneous  firing  of  a  system  net  together  with 
some  of  its  objects  “involved”  in  this  firing. 

In  this  paper  we  show  how  some  crucial  verification  problems  remain  decidable  for  ^sted  Petri  nets  and  some 
become  undecidable.  This  shows  that  nested  Petri  ne'ts  are  in  some  weaker  than  Turing  machines  and  stronger 
than  ordinary,  “flat”  Petri  nets.  The  decidability  results  are  mostly  based  on  the  theory  of  Well-Structured 
Transition  Systems  [Fin90, AC JY96,FS98]. 

The  paper  is  organised  as  follows.  Section  2  contains  definitions  of  Nested  Petri  nets.  In  Section  3  the 
expressive  power  of  nested  Petri  nets  and  some  other  Petri  nets  models  is  compared.  In  Section  4  we  prove 
that  nested  Petri  nets  are  well-structured  transition  systems  and  deduce  some  decidability  and  undecidability 
properties.  In  the  Appendix  we  give  a  simple  example  of  a  two-level  nested  Petri  net  with  ordinary  Petri  nets 
as  tokens. 

*  This  work  was  mainly  prepared  during  the  stay  of  the  first  author  at  Lab.  Specification  &c  Verification  in  June-July 
1998,  and  was  partly  supported  by  INTAS-RFBR  (Grant  95-0378)  and  the  Russian  Fund  for  Basic  Research  (Project 
No.  ^96-01-01717) 

^  The  word  “nested”  points  to  the  analogy  with  nested  sets,  containing  sets  as  their  elements,  which  in  turn  may  contain 
sets  and  so  on.  There  may  be  any  fixed  number  of  levels  in  nested  Petri  nets.  It  is  also  possible  to  consider  nested  nets 
with  unbounded  depth,  but  we  do  not  do  this  here. 
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2  Nested  Petri  Nets 

Definition  1.  Let  P  and  T  be  disjoint  sets  and  let  F  C  (P  x  T)  U  (T  x  P).  Then  M  =  {P,T,F)  is  a  net.  The 
elements  of  P,  T  and  F  are  called  places,  transitions  and  arcs  respectively. 

Pictorially,  P-elements  are  represented  by  circles,  T-elements  by  boxes,  and  the  flow  relation  F  by  directed  arcs. 
For  a:  €  P  U  r  we  write  ‘x  for  the  pre-set  {y  |  yFx}  of  x,  and  x*  for  its  post-set  {y  \  xFy).  The  input  arcs  of  a 
transition  t  are  those  in  {(x,,t)  |  x  €  *t},  its  output  arcs  are  those  in  {(t,  x)  |  x  G  t*}. 

Markings.  In  the  Coloured  Petri  nets  formalism  [Jen92],  places  carry  marked  multisets  of  coloured  tokens.  Recall 
that  a  multiset  m  over  a  set  5  is  a  mapping  m  ;  5  — ^  N,  where  N  is  the  set  of  natural  numbers,  m  is  finite  iff 
{s  G  5  I  m(s)  >  0}  is.  We  let  m  <m'  \m  -f  m')  denote  multiset  inclusion  (resp.  sum).  By  Sms  we  denote  the 
set  of  all  finite  multisets  over  S. 

Definition  2.  Let  N  -  {P,T,F)  be  a  net  and  S  an  arbitrary  set.  A  marking  of  over  S,  also  called  an 
S-marking,  is  a  function  M  from  P  to  Sms  mapping  every  place  to  a  multiset  over  S.  A  marked  net  is  a  net 
together  with  some  marking,  called  the  initial  marking  of  this  net. 

In  the  above  definition  tokens  may  be  arbitrarily  complex  objects  (as  in  Coloured  Petri  nets).  In  nested  Petri 
nets  the  tokens  may  be  nets. 


Transitions.  As  with  Coloured  Petri  nets,  we  want  to  keep  track  of  moving  tokens.  For  this  we  label  arcs  with 
variables  and  other  expressions. 

Let  V  —  {wi, . . .}  be  a  set  of  variable  names,  and  C  =  {ci , . . .}  a  set  of  constant  names.  Write  A  for  the  set 
F  U  (7  of  atoms.  An  expression  is  a  finite  multiset  of  atoms  (usually  written  with  the  binary  symbol  -f :  e.g., 
vi  -I-  (c2  -k  ui)  is  an  expression).  Pxpr(A)  is  another  way  of  denoting  Ams  -  {e, the  set  of  expressions.  For 
e  G  Expr{A),  Var{e)  is  the  set  of  variables  occuring  in  expression  e. 

Assume  any  constant  c  denotes  a  fixed  element  cs  in  S.  Assume  b  maps  any  variable  v  to  an  element  b{v)  G  S. 
Then  6(e)  denotes  a  multiset  over  S  in  the  obvious  way. 

Let  Lab  ^  {Zj ,  Z2, . . .}  and  Lab'  =  {l^,F, . . .}  be  two  disjoint  sets  of  labels.  For  each  label  I  e  Lab  U  Lab'  we 
define  an  adjacent  label  Z,  such  that  the  sets  Lab,  Lab',  Lab  =def  {I  |  I  e  Lab}  and  W  =def  {F  |  Z'  G  Lab'}  are 
pairwise  disjoint.  Let  Z  =def  Z  and  £  =def  Lab  U  Lab'  ULabU  'Lab'. 

Now  we  come  to  the  definition  of  a  nested  Petri  net  structure,  consisting  of  a  system  net,  several  object  nets 
labels  on  arcs,  and  labels  on  transitions.  ’ 


Definition  3.  A  nested  Petri  net  structure  i7  is  an  array  ofk>l  nets  M ,  •  - . ,  A4,  where  Ai  is  a  distinguished 
net,  called  a  system  net,  and  the  Mi ’s,  for  i  =  2,...,k,  are  called  object  nets. 

In  any  A  =  {Pi,Ti,Fi)  the  input  (resp.  output)  arcs  from  Fi  are  labeled  by  expressions  £{p,t)  (resp  £{t  p)) 
from  ExpriA).  We  require  that  no  variable  occurs  twice  in  an  input  label  £{p,t),  or  in  two  input  labels  for  a 
same  transition.  (There  is  no  restriction  on  the  output  labels.) 

In  any  Mi,  the  transitions  may  carry  labels  from  £  (possibly  several  labels). 


Assume  a  given  nested  Petri  net  structure  S  and  let  markings  in  object  nets  A2, . . . ,  Afe  be  considered  over 
some  fimte  sets  S2, . . .  correspondingly  and  let  M  denote  the  set  of  all  marked  object  nets  of  S. 

Definition  4.  A  nested  Petri  net  (NP-net)  is  a  nested  Petri  net  structure  S  with  each  constant  c£  C  inter¬ 
preted  as  some  marked  object  net  from  M. 

By  a  marking  of  a  NP-net,  we  mean  a  marking  of  its  system  net  over  the  set  M. 

A  marked  NP-net  is  an  NP-net  together  with  some  (initial)  marking. 

Note  that  the  definition  of  an  NP-net  depends  on  the  sets  ^2, . . . ,  5*  as  parameters.  If  the  S£s  are  one-element 
sets,  then  the  object  nets  are  ordinary  Petri  nets  with  black  dots  as  tokens,  and  a  nested  Petri  net  Is  just  a 
^stem  net  with  ordinary  nets  as  tokens.  If  the  Si’s  are  sets  of  coloured  tokens,  then  a  nested  Petri  net  has 
Coloured  Petri  nets  as  tokens.  If  the  Si’s  are  sets  of  marked  nets,  we  get  a  three-levels  (or  more)  structure,  in 
which  object  nets  are  system  nets  with  respect  to  the  next  level.  It's  clear  that  we  can  have  as  many  levels  as 

we  hke.  And  at  last,  if  some  of  sets  S2,  S3,...,Sk  contain  the  system  net  Ai,  as  its  element  we  get  recursion 
which  IS  not  considered  here.  ’ 


In  NP-nets,  firing  a  transition  requires  instantiating  the  variables  in  arc  labels: 
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Definitions.  LetJ\fi  =  {Pi,Ti,Fi)beanetinanestednetNPN. 

1.  A  binding  of  a  transition  t  e  Ti  is  a  function  b  mapping  each  variable  v  e  V  to  a  value  b{v)  from  the  set 
MuS2\JS^U  ...USk- 

2.  A  binded  transition  is  a  pair  Y  =  (t,  b),  where  t  is  a  transition  and  b  is  a  binding  oft. 

3.  A  binded  transition  Y  —  {t,b)  is  enabled  in  a  marking  M  of  Afi  iff 'ip  G  :  b{£(p,t))  C  M{p). 

4-  An  enabled  binded  transition  Y  —  {t,b)  may  fire  in  a  marking  M  and  yield  a  new  marking  M',  written 
M[Y)M'.ForanypePi,M'(p)=^^fM(p)-b{£{p,t))+b{S{t,p)). 

Now  we  come  to  defining  a  step  in  a  NPN-net. 

Definition  6.  Let  NPN  be  an  NP-net.  A  step  of  NPN  is  either 

a  transport  step:  firing  (through  some  appropriate  binding)  an  unlabeled  transition  in  the  system  net  Mi,  not 
changing  markings  of  object  nets; 

an  object-autonomous  step:  firing  an  unlabeled  transition  in  one  of  the  object  nets,  while  all  object  nets 
remain  in  the  same  places  of  the  system  net; 

an  horizontal  synchronisation  step:  simultaneous  firing  of  two  transitions  of  two  object  nets  lying  in  the 
same  place  w.r.t.  the  same  binding,  provided  these  two  transitions  are  marked  by  two  adjacent  labels  I  and 
I  from  Lab'  U  Lab' ; 

a  vertical  synchronisation  step:  simultaneous  firing  of  a  transition  t  marked  by  a  label  I  €  LabULab  in  the 
system  net  and  transitions  in  object  nets  marked  by  the  same  label  I  —  one  in  each  net  from  the  multiset 
£(p,t){b)  for  each  p  E  *t  w.r.t.  the  same  binding. 

We  say  a  marking  M'  is  (directly)  reachable  from  a  marking  M  and  write  M  — >  M' ,  if  there  is  a  step  in  NPN 
leading  from  M  to  M'. 

An  execution  of  NP-net  NPN  is  a  sequence  of  markings  Mo  Mi  M2  . . .  successively  reachable  from  the 
initial  marking  Mo- 


3  Nested  Petri  nets  and  other  Petri  net  models 

In  this  section  we  compare  expressive  power  of  nested  Petri  nets  with  some  other  Petri  net  models.  First  of  all, 
it  was  already  explained,  that 

Proposition  1.  Ordinary  Petri  nets  form  a  special  case  of  nested  Petri  nets. 

Then  we  compare  nested  Petri  nets  with  some  extensions  of  ordinary  Petri  net  model. 

Petri  nets  with  reset  arcs  [Cia94]  extend  the  basic  model  with  special  “reset”  arcs,  which  denote  that  firing 
of  some  transitions  resets  (empties)  the  corresponding  places. 

Theorem  1.  Petri  nets  with  reset  arcs  can  be  simulated  by  nested  Petri  nets  with  ordinary  Petri  nets  as  object 
nets. 

Proof  The  idea  is  to  simulate  the  presence  of  n  tokens  by  one  simple  object  net  having  n  tokens.  Then  it  is 
possible  to  remove  this  object  net  in  one  step  (and  replace  it  by  an  empty  object  net),  simulating  the  effect  of  a 
reset  arc.  Incrementations  and  decrementations  in  the  object  nets  simulate  incrementations  and  decrementations 
in  a  place  of  the  system  net.  They  can  be  enforced  by  the  synchronisation  mechanism. 

Since  it  is  known  [DFS98,DJS99]  that  Petri  nets  with  reset  arcs  are  more  expressive  than  ordinary  Petri  nets, 
we  immediately  get  the  following 

Theorem  2.  Nested  Petri  nets  with  ordinary  Petri  nets  as  object  nets  are  more  expresrive  than  “flat”  ordinary 
Petri  nets. 

4  Decidability  for  Nested  Petri  Nets 

In  this  section  we  discuss  some  issues  of  decidability  for  nested  Petri  nets.  First,  we  briefly  formulate  some 
problems  crucial  for  verification  of  Petri  nets. 

A  net  terminates  if  there  exists  no  infinite  execution  {Termination  Problem).  A  marking  M'  is  reachable 
from  M,  if  there  exists  a  sequence  of  steps  leading  from  M  to  M'  {Reachability  Problem).  The  reachability 
set  of  a  net  is  the  set  of  all  markings  reachable  from  the  initial  marking.  A  net  is  bounded  if  its  reachability 
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set  is  finite  {Boundedness  Problem).  The  Control-State  Maintainability  Problem  is  to  decide,  given  an  initial 
marking  M  and  a  finite  set  Q  =  {^i,  92, . . . ,  9,71}  of  markings,  whether  there  exists  a  computation  starting  from 
M  where  all  markings  cover  (are  not  less  than  w.r.t.  some  ordering)  one  of  the  qi's.  The  dual  problem  called 
the  Inevitability  Problem,  is  to  decide  whether  all  computations  starting  from  M  eventually  visit  a  state  not 
covering  one  of  the  qi’s,  e.g.  for  Petri  nets  we  can  ask  whether  a  given  place  will  eventually  be  emptied. 

Theorem  3.  1.  Reachability  is  undecidable  for  nested  Petri  nets. 

2.  Boundedness  is  undecidable  for  nested  Petri  nets. 


Proof  Due  to  Theorem  1  Nested  Petri  nets  can  simulate  Petri  nets  with  reset  arcs,  hence,  validity  of  this  two 
statements  follows  from  undecidability  of  reachability  [AK77]  and  boundedness  [DFS98,DJS99l  for  Petri  nets 
with  reset  arcs.  , 

□ 

To  obtain  decidability  results  we  use  the  notion  of  well-structured  transition  system  introduced  in  [Fin90  ACJY961 
Recall  that  a  transition  system  is  a  pair  S  =  {S,  ->)  where  S'  is  an  abstract  set  of  states  (or  configurations) 
transition  realtion.  For  a  transition  system  S  =  (S,->)  we  write  Succis)  for  the  set 
\s  e  6  I  s  -)■  5  j  of  immediate  successors  of  s.  S  is  finitely  branching  if  all  Succ{s)  are  finite. 

A  well-structured  transition  system  is  a  transition  system  with  a  compatible  wqo:  recall  that  a  quasi-ordering 
(a  qo)  is  any  reflexive  and  transitive  relation  <  (over  some  set  X). 

Definition  7.  A  well-quasi-ordering  (a  wqo)  is  any  quasi-ordering  <  such  that,  for  any  infinite  sequence 
Xo,Xi,X2,. .. ,  in  X,  there  exist  indexes  i  <  j  with  Xi<Xj. 


Note,  that  if  <  is  a  wqo,  then  any  infinite  sequence  contains  an  infinite  increasing  subsequence:  Xi^  <  Xi^  <Xi2... 

Definition  8.  A  well-structured  transition  system  (a  WSTS)  is  a  transition  system  S  ^  (S  -^  <)  eauivved 
with  an  ordering  <C,  S  x  S  between  states  such  that  'J  yy 

-<  is  a  wqo,  and 


-  <  is  “compatible”  with 

where  “mmpatible”  means  that  for  all  si<ti,  and  transition  si  ->  sa,  there  exists  a  transition  h  t2,  such 
mat  52  <  t2*  ^ 


[FS98,FS97]  introduce  more  liberal  notions  of  compatibility: 

A  WSTS  E  has  transitive  compatibility  if  for  all  si  <  ti,  and  transition  si  -4  S2,  there  exists 
sequence  ti t2 -t . . . ->  tn  with  §2  < 

A  WSTS  E  has  stuttering  compatibility  if  for  all  si  <ti,  and  transition  Si  S2,  there  exists 
sequence  ->•  with  S2  <  and  Si  <  ti  for  all  i  <  n. 

Now  we  define  a  wqo  on  the  set  of  states  of  our  NP-nets  and  show  that  they  are  WSTS. 


a  nonempty 
a  nonempty 


Definition  9.  Let  NPN  be  a  nested  Petri  net,  Mms  —  the  set  of  all  its  states. 

A  quasi-ordering  ^  on  Mms  is  defined  as  follows: 

^  ^  injective  function  jp  :  Mi{p)  M2(p),  such 

e  Mi(p),  for  s  e  Mi(p);  either  jp(s)  =  s  or  s  =  {Afi,m)  and  3p{{Afi,m))  ^  {Afj,m‘)  implies 


Thus,  the  relation  ^  is  a  kind  of  a  nested  set  inclusion.  ‘  ^ 

Proposition  2  Let  NPN  be  a  nested  Petri  net,  with  Mm's  the  set  of  all  its  states,  ->  the  step  relation  on 
Mms,  and  <  the  quasi- ordering  on  Mms,  defined  above.  Then  {Mms,  -^,<)  is  a  well-structured  transition 


We  skip  the  proof  here. 

we  would  not  restrict  multiple  occurrences  of  variables  in  input  arc  expressions,  we  would  not 
have  WSTS,  as  well  as  Object  Petri  nets  of  Valk  are  not  WSTS. 

It  was  proved  in  [FS97]  that 


Sw^sHTheorem^?)^^  WSTS’s  with  (1)  transitive  compatibility,  (2)  decidable  <,  and  (3)  effective 

-  The  control-state  maMainabihty  problem  and  the  inevitability  problem  are  decidable  for  WSTS’s  with  fli 
stuttering  compatibility,  (2)  decidable  <,  and  (3)  effective  Succ{s).  (Theorem  4.8.) 

It  turns  out  that  for  NP-nets 
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Lemma  1.  (1).  The  qo  ■<  is  decidable. 

(2).  Succ  is  effective. 

With  the  help  of  these  statements  we  can  obtain  the  following  decidability  results  for  NP-nets: 

Theorem  4.  Termination  is  decidable  for  nested  Petri  nets. 

Proof.  Follows  from  Proposition  2,  Lemma  1  and  Theorem  4.6  in  [FS97].  O 

Corollary  1.  Nested  Petri  nets  are  expressively  strictly  weaker  than  Turing  machines. 

Proof  Since  termination  is  not  decidable  for  Turing  machines.  D 

Theorem  5.  The  control-state  maintainability  problem  and  the  inevitability  problem  (w.r.t.  ■<)  are  decidable 
for  nested  Petri  nets. 

Proof  Follows  from  Proposition  2,  Lemma  1  and  Theorem  4.8  in  [FS97].  □ 
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A  Appendix:  Example 

wlTtit?  ^  two-level  nested  Petri  net.  It  models  a  set  of  worker  receiving  some  tasks  from 

time  to  time  When  a  task  comes,  a  worker  is  to  borrow  a  tool  from  the  buffer  of  tools.  The  Lmber  of  workers 
mvo  ved  in  this  system  is  unlimited.  The  behaviour  of  each  worker  is  described  by  the  same  object  net  which  is 
an  elementaxy  Petri  net  The  system  net  describes  a  buffer  of  tools.  The  number  of  tools  is  fixed  and  is  initiallv 
represented  by  the  number  of  tokens  in  the  place  55 .  ^ 


Element  net  for  a  Worker 


The  substantive  meaning  of  places  in  an  object  net  is  as  follows:  T  —  set  of  tasks  for  a  worker-  w 
rX^Lg  Lto^  '  "  a  task;  a’w»k« 

witi”  ZbTi  «  jen;  5s  -  workers,  applying  for  a  tool;  5,  -  wotkem 

havig  a  zc  :',?vi“e;  wfs  ^  ‘ 
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Abstract.  We  relate  two  major  paradigms  of  mobile  computation,  namely  concurrent  constraints  and 
n-calculus.  We  first  define  a  minimal  calculus  which  contains  the  core  features  of  concurrent  constraint 
paradigm,  and  then  provide  an  embedding  from  it  to  the  n-calculus.  Within  such  a  framework,  we  define 
a  notion  of  behavioral  congruence  on  concurrent  constraints,  and  demonstrate  that  it  corresponds  to  weak 
barbed  congruence  in  7r-calculus. 


1  Motivation 

There  has  been  a  proliferation  in  the  number  of  models  that  are  being  proposed  to  study  concurrent  computation. 
Given  such  a  situation,  it  is  imperative  to  relate  such  models  in  order  to  evaluate  their  relative  benefits  and 
drawbacks,  and  to  carry  over  successful  analysis  techniques  across  models.  Such  an  enterprise  should  relate  at 
least  two  benchmark  work  models  of  concurrency  that  are  most  expressive  and  widely  used.  This  paper  takes  a 
step  in  that  direction. 

In  the  design  space  of  models  for  concurrency,  there  are  two  major  paradigms  which  have  been  shown  to 
possess  an  expressive  power  of  astounding  range,  namely  ^.he  concurrent  constraint  paradigm  [1, 14, 16]  and  the 
TT-calculus  [4, 5, 7].  Each  of  them  have  been  shown  to  be  capable  of  embedding  various  other  models  of  sequential 
and  concurrent  computation  as  special  cases  of  themselves  [7, 11, 14, 15].  The  expressive  power  of  these  models 
essentially  derives  from  their  ability  to  model  the  key  notion  of  mobility  elegantly,  within  a  first-order  framework. 

The  above  two  paradigms  appear  to  be  completely  divergent  from  each  other.  This  is  not  surprising  since 
they  evolved  from  distinct  sub-disciplines  of  computer  science.  The  7r-calculus  (Pl)  uses  communicating  processes 
which  evolve  concurrently,  and  interact  by  passing  messages  along  named  channels.  In  order  to  model  mobility, 
it  suffices  to  restrict  the  communicated  data  values  to  be  channel  names  only.  On  the  other  hand,  the  concurrent 
constraints  paradigm  (CCP)  uses  concurrent  processes  which  evolve  by  adding  and  resolving  constraints  on  logical 
variables.  In  order  to  represent  mobility,  it  suffices  to  deal  with  equational  constraints,  and  use  unification  as  the 
resolution  mechanism.  The  differences  in  the  primitives  of  the  two  paradigms  gives  them  their  distinct  flavour, 
but  also  makes  the  task  of  relating  them  a  non-trivial  one. 

The  difficulty  in  relating  the  two  paradigms  can  be  seen  by  examining  related  research  work.  Most  of  the 
related  work  which  embed  {variants  of)  CCP  into  pi  have  used  additional  features  over  and  above  the  basic 
primitives  of  Pl  in  order  to  succeed.  The  embedding  proposed  by  Victor  and  Parrow  [18]  is  the  only  exception 
to  this  rule.  However  their  proposal  is  inadequate,  since  their  translation  of  logic  variables  leads  to  deadlocks 
during  concurrent  update  operations  on  the  logic  variables.  We  discuss  this  aspect  in  Section  5  while  examining 
related  work.  ‘ 

In  this  paper,  we  relate  the  two  major  paradigms  of  mobile  computation  -  concurrent  constraints  and  tt- 
calculus.  Significant  contributions  of  the  work  are  summarized  below: 

1.  It  defines  a  minimal  calculus  which  contains  the  core  features  of  the  concurrent  constraint  paradigm. 

2.  It  defines  a  notion  of  behavioral  congruence  on  concurrent  constraints  and  demonstrates  that  it  corresponds 
to  weak  barbed  congruence  in  7r-calculus. 

3.  As  far  as  our  knowledge  goes,  this  is  the  first  work  that  gives  a  correct  translation  from  the  essential 
features  of  CCP  to  the  minimal  Pi,  without  requiring  any  additional  enhancements  to  the  basic  primitives 
of  TT-calculus. 

4.  It  relates  two  major  paradigms  of  mobile  computation,  which  are  based  on  totally  orthogonal  primitives.  In 
a  sense,  this  opens  up  possibilities  of  exploring  new  paradigms  of  mobility,  which  use  a  judicial  mix  of  the 
characteristics  of  concurrent  constraints  and  w-calculus. 
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2  Two  paradigms  of  mobility 

We  follow  the  notion  of  paradigm  of  mobility  as  given  by  Milner,  Parrow,  and  Walker  [4],  and  define  it  as  given 
below: 

Definition  1  (Mobility  Paradigm).  A  paradigm  of  concurrent  computation  is  said  to  be  a  paradigm  of  mo¬ 
bility  provided  it  can  model  the  behaviour  of  systems  whose  component  processes  may  be  arbitrarily  linked,  and 
can  also  model  the  fact  that  communication  between  component  processes  of  the  system  may  carry  information 
which  modifies  that  linkage. 


2.1  Paradigm  of  7r-Calculus 

In  the  following,  we  present  a  brief  overview  of  rr-calculus  [4, 5].  For  more  details,  the  reader  is  referred  to  [4, 
5].  The  TT-calculus  (pi)  is  a  process  algebra  that  has  two  kinds  of  basic  entities  -  names  (channels)  (x  v  z  1 
axiA  processes  {agents)  {P,Q,...).  '  ’ 

Definition  2.  Names  {x,y, . . .  £  X),  have  no  structure,  while 
Processes  (P,  Q, . . .  £  P)  possess  a  well  defined  structure  given  by 
P::=  0  I  xiy).P  |  ^y].P  |  P\Q  \  p  +  Q  |  \p  \  {ux)P  I 
[x  =  y]{P,Q)  [  A(2/i,...,y„)  ' 

where,  X  and  y  denote  finite  sequences  of  names. 

Basic  actions  in  pi  constitute  sending  or  receiving  names  on  channels.  Process  x{y).P  inputs  a  name,  say  y, 
along  X,  and  binds  y  in  P.  Process  ^z].Q  outputs  the  name  2:  along  x,  but  does  not  bind  a.  The  basic  rule 
of  computation  in  pi  is  provided  by  the  parallel  composition  of  processes  which  communicate  along  the  same 
channel:  . 


x{y).P  I  x[z].Q  -^p{y^^z}\Q 

In  the  above  interaction,  the  process  x{y).P  receives  the  channel  a  from  the  process  ^z].Q  over  the  channel  x, 
and  gets  modified  to  P{y  -e-  z},  where  the  name  z  replaces  appropriate  instances  of  name  y.  Further  evolution 
of  F{y  £-  may  get  crucially  affected  by  the  arrival  of  the  name  Thus  pi  supports  mobility  by  naming 
and  passing  channels.  Communication  consists  in  synchronously  sending  arid  receiving  through  a  shared  labeled 
channel.  It  consciously  forbids  the  transmission  of  processes  as  messages.  One  of  its  goals  is  to  demonstrate  that 
m  some  sense  it  is  sufficiently  powerful  to  allow  only  names  to  be  the  content  of  communications. 

The  term  0  represents  an  inactive  process,  which  cannot  perform  any  action.  We  shall  omit  the  trailing  “.0” 
from  process  terms.  The  form  P  +  Q  means  that  the  process  can  indulge  in  precisely  one  of  the  alternatives 
given  by  P  and  Q,  for  communication.  The  operator  “!”  is  called  replication  {Bang),  and  !P  means  PIPI . .  .•  as 
many  copies  as  you  wish.  The  format  {px)P  restricts  the  use  of  name  x  to  P.  Apart  from  input  prefix  ‘V”  is 
another  mechanism  for  binding  names  within  a  process  term  in  Pi.  The  operator  ‘V”  may  also  be  thought  of  as 
creating  new  channels.  The  match  form  [x  =  y](P,  Q)  process  behaves  like  P  if  the  names  x  and  y  are  identical, 
and  otherwise  like  Q.  Agent  identifiers  A  have  a  fixed  arity  and  a  unique  defining  equation  A{xi , . . . ,  a:„)  P. 

The  operational  semantics  of  pi  is  given  in  Wo  stages.  A  structural  congruence  is  first  defined  over  processes 
and  then,  a  reduction  relation  is  defined.  > 


Definition  3  (Structural  Congruence  over  Processes), 
cesses  such  that  the  following  laws  hold: 


=  is  the  smallest  congruence  relation  over  pro- 


i.  Processes  are  identified  if  they  only  differ  by  a  change  of  bound  names. 
■2-  (P/  =,+,0)  is  an  abelian  monoid. 

S.  (P/  =,  1,0)  is  an  abelian  monoid. 

4.  !P  =  Pi!P 

5.  {i'x)0  =  0,{px){py)P  =  {i^y){i^x)P 

6.  {ux){P\Q)  =  P\{ux)Q  if  a;  ^  FreeName{P). 

7.  A{x)  =  P{y  £-  x}  if  A{y)  P  and  \x\  =  \y\ 
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Definition  4  (Reduction  Relation).  The  reduction  relation 
fying  the  following  rules: 


Comm 

■  +  x{y).P) 

1  {x[z].Q  +  ...\ 

Par 

(PIQ)-^(P'IQ) 

Match 

[x 

=  x]iP,Q) 

->  P 

Mismatch 

[x 

^ymQ) 

->  Q  if  X  ^y 

Struct 

P-^P' 

P’=Q' 

Q-4Q' 

Res 

p-^p' 

->■  over  processes  is  the  smallest  relation  satis- 

P{y  f-  5}  I  Q  if  \y\  =  \z\ 


Note  that  the  rules  do  not  allow  reduction  under  prefix,  sum,  or  replication. 

Following  [5, 8],  we  define  a  notion  of  equivalence  for  Pi. 

Definition  5  (Unguarded  Occurrence).  A  process  Q  occurs  unguarded  in  P  if  it  has  some  occurrence  in 
P  which  is  not  under  a  prefix.  , 

Definition  6  (Observable  Action).  A  process  P  can  perform  an  observable  action  at  x,  written  P  la,,  if 
for  some  x,y,  the  input  prefix  x{y).Q  occurs  unguarded  in  P  with  x  unrestricted;  A  process  P  can  perform  an 
observable  action  at  x,  written  P  if  for  some  x,y,  the  output  prefix  x[y].Q  occurs  unguarded  in  P  with  x 
unrestricted. 


Let  denote  the  transitive  reflexive  closure  of  “-t”. 

Definition  7  (Weak  Barbed  Equivalence).  A  relation  over  processes,  is  a  Weak  Barbed  Relation,  if 
P  Ryj  Q  implies: 

1.  For  each  x,  P  4.3;  implies  35  s.t.  Q  -¥*  5  4-3,. 

2.  For  each  x,  P  4.^  implies  35  s.t.  Q  ->*  5  4-*. 

3.  IfP-^  P'  then  Q  ->■*  Q'  and  P'  Ry,  Q'; 

The  relation  R^  is  a  Weak  Barbed  Equivalence  if  R  and  R~^  are  Weak  Barbed  Relations.  Two  processes  P 
and  Q  are  Weak  Barbed  Equivalent,  if  P  Ry,  Q  for  some  Weak  Barbed  Equivalence  Ry,. 

Definition  8  (Process  Context).  A.  Process  Context  C[  ]  is  a  process  term  with  a  single  hole,  such  that 
placing  a  process  in  the  hole  yields  a  well-formed  process. 

Definition  9  (Weak  Barbed  Congruence).  Two  processes  P  and  Q  are  Weak  Barbed  Congruent,  written 
P  Q,  if  for  each  process  context  C\  ],  it  holds  that  C[P]  is  Weak  Barbed  Equivalent  to  C[Q]. 


2.2  Paradigm  of  Concurrent  Constraints 

In  the  following,  we  present  a  brief  overview  of  a  minimal  calculus  which  contains  the  core  features  of  the 
concurrent  constraint  paradigm  [1, 14, 16].  For  more  details,  the  reader  is  referred  to  [1, 14, 16].  The  concurrent 
constraint  paradigm  (CCP)  is  a  formalism  that  has  two  kinds  of  basic  entities  -  logic  variables  {hM,...) 
and  agents  (A,  B, . . .).  Basic  actions  in  ccp  constitute  telling  and  asking  constraints  on  logic  variables.  Agent 
tell{c)  ->  A  adds  the  constraint  ‘c’  to  the  constraint  set  (fails  if  it  is  not  possible  to  do  so  while  preserving 
consistency)  and  then  behaves  like  A.  The  agent  ask(c)  ->  A  awaits  until  the  store  entails  the  constraint  ‘c’, 
and  then  it  behaves  like  A.  The  basic  rule  of  computation  in  ccp  is  provided  by  the  constraint  resolution  - 
mechanism  (unification),  which  gives  rise  to  bindings  on  logic  variables  as  a  side  effect. 

Modeling  of  mobility  in  the  CCP  paradigm  can  be  understood  informally  by  the  following  scenario.  Consider 
a  situation  with  two  agents  A  and  B,  one  global  logic  variable  I,  and  two  local  logic  variables  la  and  h  which  are 
local  to  A  and  B  respectively.  The  logic  variables  denote  communication  channels,  and  the  constraint  resolution 
(unification)  implements  the  communication  mechanism.  Suppose  agent  A  wants  to  transmit  its  local  variable  la 
to  the  agent  B.  This  can  be  achieved  by  the  parallel  composition  of  the  CCP  agent  terms  A  =  3la.tell{l  =  la) 
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and  B  =  3li,.ask{l  =  4)- Agent  ^4 ‘tells’ a  constraint  which  identifies  the  global /  and  locaUa- Agent  5  waits 
for  this  constraint  to  get  added,  and  when  it  ‘asks’  for  such  a  constraint,  it  identifies  the  global  I  and  local  If,. 
The  unification  mechanism  completes  the  communication  by  effectively  binding  la  to  h,  thus  transmitting  la 
from  Ato  B,  along  1.  fri  order  to  achieve  mobility,  it  is  sufficient  to  restrict  the  constraint  mechanism  to  just 
equational  constraints  over  logic  variables: 


Definition  10.  Let  Nat  denote  the  natural  numbers  (0, 1, ...  G  Nat); 

Logic  Variables  (/,/i,/2,...  €  JC)  have  no  structure; 

Constraints  (c,c', . . .  G  C)  are  given  by  c  :~  1  =  Nat  | 

Agents  (.4, B,...  £  A)  are  given  by 

A  ask{c) A  \  tell{c)  ^  A  \  nil  \  A  i|  A  |  A®A  \  Bl.A  \  P{x) 

Declarations  are  given  by  D  y.—  e  \  P(y)  :  ~  A.  ' 

Each  agent  has  an  associated  local  store  with  it.  Further  there  is  a  global  store  which  is  accessible  to  all  the 
agents.  The  local  store  contains  constraints  on  the  local  variables,  while  the  global  store  contains  constraints 
on  the  global  variables.  The  basic  actions  are  given  by  ask[c)  and  tell{c)  constructs,  where  c  is  a  constraint. 
The  symbol  ‘-4’  denotes  the  prefix  operation.  The  agent  ask{c)  -4  A  awaits  until  the  store  entails  c  and  then 
it  behaves  like  A.  The  agent  tell{c)  A  adds  c  to  the  store  and  then  it  behaves  like  A.  Operations  ask{c) 
and  tell{c)  fail  when  c  is  inconsistent  with  the  store.  The  term  nil  represents  an  inabtive  agent,  which  cannot 
perfonn  any  action.  We  shall  omit  the  trailing  “-4  nil”  from  agent  terms.  Operators  ||  and  ©  denote  the  parallel 
composition  and  nondeterministic  choice  respectively.  Agent  31.  A  is  the  same  as  agent  A,  except  that  variable  I 
is  treated  as  local.  The  term  P(x)  denotes  a  procedure  call,  where  P  is  the  name  of  the  procedure  and  x  denotes 
the  actual  parameters.  The  meaning  of  P{x)  is  given  by  a  procedure  declaration  of  the  form  P{y)  :  -  A,  where 
y  denotes  the  formal  parameters.  We  shall  assume  that  for  every  procedure  name  there  exists  precisely  one 
declaration  in  £>. 

Constraints  are  equalities  over  the  basic  signature  consisting  of  logical  variables  and  the  natural  numbers. 
Store  is  a  set  of  constraints  (equalities).  We  shall  use  C  to  range  over  sets  of  constraints.  Entailment  of  a 
constraint  c  by  C  will  be  written  Che;  and  consistency  of  a  constraint  set  will  be  denoted  by  C  1/  false.  The 
formal  definition  of  the  operational  semantics  exploits  a  relation  —4  between  elements  of  V  (Processes),  where 
^  =  {<  A,  cT  >  I  A  is  an  agent  term,  u  is  a  store}. 

Definition  11  (Structural  Congruence  over  Processes).  =  is  the  smallest  congruence  relation  over  pro¬ 
cesses  such  that  the  following  laws  hold: 


1.  Processes  are  identified  if  they  only  differ  by  a  change  of  bound  names. 

2.  <  A,C  >=<  A,C'  >,  if  C  implies  C  and  C'  implies  C. 

S-  (P/ =,©,m7)  is  an  abelian  monoid. 

4-  (fP I  =, \\,nil)  is  an  abelian  monoid. 

5.  (3l)nil  =  nil,  {3li)(3l2)A  =  (3l2)(3li)A. 

fi.  If  /  ^  FreeName{A)  then  (3/)(.A  \\B)  =  A  ||  {3l)B. 

Definition  12  (Reduction  Relation).  The  reduction  relation  4^  over  processes  is  the  smallest  relation  sat¬ 
isfying  the  following  rules: 


Ask 

Tell 

Sum 

Par 


CJ-c 


<ask(c)-^A,  0 

— +  <A,  C> 

Che  false 

<tell{c)-^A,  0 

— >  <A,  CAO 

<Ai,  C>  — > 

<A', ,  0 

<Ai©A2,  C>  — 

4  <A[,  0 

<Ai,  C>  — 

>  <A\,  0 

<Ai|iA2,  C>  — >  <A;||A2,  C'> 


Res  C>  —4  <A',  C'>  I2  is  a  fresh  variable 

<3li.A,  C>  —4  <A',  C>> 


PrOCCall  C>  — »  <A',  C'>  where  P(ij):-A 

<P(5),  0  — >■  <A',  O 
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Definition  13  (Unguarded  Occurrence).  Process  B  occurs  unguarded  in  A  if  B  has  some  occurrence  in  A 
which  is  not  under  a  prefix. 

Definition  14  (Observable  Action).  Process  A  can  perform  an  observable  action  at  x,  written  A  if  for 
some  X,  I,  either  the  prefix  ask{x  —  l)-^Bor  the  prefix  ask{x  —  Nat)  -t  B  occurs  unguarded  in  A,  where  x  is 
not  bound  by  the  3  operator;  Process  A  can  perform  an  observable  action  at  x,  written  A  \.x,  if  for  some  x,l, 
either  the  prefix  teU{x  =  1)  B  or  the  prefix  tell{x  =  Nat)  ->  B  occurs  unguarded  in  A,  where  x  is  not  bound 
by  the  3  operator. 

Definition  15  (Weak  Reduction  Equivalence).  A  relation  Ru,  over  processes,  is  a  Weak  Reduction  Rela¬ 
tion,  if  A  Rw  B  implies:  (a)  Va:,  A  la,  implies  3E  s.t.  B  — >*  E  J-x  (b)  Nx,  A  4.x  implies  3E  s.t.  B  • — E  4.x 
(c)  If  A  — >  A'  then  B  — >*  B'  and  A'  R^^  B' ;  where  “ — ^*”  denotes  the  transitive  reflexive  closure  of  “ — 
Relation  R^  is  a  Weak  Reduction  Equivalence  if  R  and  R~^  are  Weak  Reduction  Relations.  Processes  A  and 
B  are  Weak  Reduction  Equivalent,  if  A  Rw  B  for  some  Weak  Reduction  Equivalence  Rw 

Definition  16  (Process  Context).  A  Process  Context  C[]  is  a  process  term  with  a  single  hole,  such  that 
placing  a  process  in  the  hole  yields  a  well-formed  process. 

Definition  17  (Weak  Reduction  Congruence).  Two  processes  P  and  Q  are  weak  reduction  congruent, 
written  P  Q,  if  for  each  process  context  C[],  it  holds  that  C[P]  is  weak  reduction  equivalent  to  CIQ]. 

3  Embedding  CCP  in  PI 

A  formal  embedding  from  CCP  to  pi  is  described  briefly  in  the  following  subsections.  This  will  form  a  semantic 
foundation  for  CCP  in  terms  of  PI. 

3.1  Translating  logic  variables 

The  formal  translation  of  logic  variables  is  shown  in  Figure  1.  There  are  two  basic  requirements  that  have  to 
be  satisfied  in  the  translation  of  logic  variables: 

—  Enforce  an  ordering  relation  so  that  unwarranted  deadlocks  during  unification  are  avoided. 

—  Preserve  ‘write  once,  read  often’  property  of  logic  variables. 

The  basic  entity  of  CCP  is  the  logic  variable.  We  assume  an  implicit  injective  function  which  maps  any  given 
CCP  logic  variable  (Iccp)  to  a  pi  name  (Ipi).  Hence  we  can  use  I  to  represent  both  Iccp  and  Ip,,  and  the  context 
will  uniquely  determine  the  entity  that  I  denotes.  , 

A  CCP  logic  variable  I  is  translated  to  a  Pi  process  InitLV ar{l)  which  performs  certain  initialization  actions, 
and  thereafter  gets  transformed  to  LVar{l,i).  The  initialization  phase  involves  interaction  between  InitLV ar{l) 
and  the  process  OrderLVar{z),  which  constructs  a  total  ordering  relation  on  logic  variables.  The  process 
OrderLVdr{z)  interacts  sequentially  with  one  logic  variable  at  a  time,  and  orders  them  in  a  list.  The  list  begins 
at  location  z,  and  incrementally  adds  an  element  for  each  logic  variable.  The  address  i  at  which  an  element 
corresponding  to  the  logic  variable  I  is  to  be  located  is  communicated  by  InitLV ar{l)  to  Order LV ar{z) .  Each 
element  of  the  list  can  be  thought  of  as  a  record  which  contains  two  pointers  -  one  to  the  process  iyar(/,*) 
corresponding  to  the  logic  variable  I,  and  another  pointer  to  the  location  of  the  previous  element  of  the  list.  The 


\LogicV ariahle\  I  =  InitLV ar{l) 

InitLVar{l)  =g[l,  ui].LVar{l,i) 

Order LVar{z)  ==  9{l,i).  (  !i[z,  i]  |  Order LVar{i)  ) 
LVar(l,  i)  =  l[-l,  l,i].LVar{l,  i) 

+ 

l{k).{k(s,n).\i[s,n,i]  -t  k.LVar{l,i)) 


Pig.  1.  Translation  of  logic  variables  and  ordering  mechanism 
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|asA:(Zi  h)  }  s,f  =  Ask{li,l2,s,f) 

Ask{h,l2,s,f)  =  [li=l2] 

(s, 

h(xi,X2,X3). 

h(m,W2,W3). 

[xi  =  IXl] 

{[X2  =  W2] 

{s,  . 

[xi  =  0] 

(/, 

Ask(x2,W2,8,  f) 

) 

), 

Ask{x2,W2,s,  f) 

) 

) 


Fig.  2.  Translation  of  ‘Ask’  action 


logic  variable  which  occurs  earlier  in  the  list  maintained  by  Order LV ar[z)  has  greater  priority  over  the  other 
logic-variable  which  occurs  later.  Such  an  order  would  be  a  superfluous  overhead  in  case  we  had  been  considering 
sequential  constraint  programming  systems.  But  it  is  useful  in  the  translation  of  concurrent  constraint  systems, 
as  a  precaution  against  deadlocks  in  the  translation  of  the  dynamics  of  unification  mechanism.  The  possibility 
of  deadlock  arises  while  trying  to  avoid  circularities  in  the  equivalence  trees  of  unified  logic  variables. 

Ensuring  “write  once,  read  often”  property 

A  logic  variable  can  be  unified  to  a  distinct  constant  only  once;  any  further  attempts  to  unify  it  with  the  same 
constant  succeed,  while  subsequent  attempts  to  unify  with  distinct  constants  fail.  However  a  logic  variable  can 
be  unified  to  any  number  of  distinct  logic  variables  as  long  as  consistency  allows  such  a  unification.  Thus  a  logic 
variable  can  be  m  any  one  of  the  three  distinct  states  -  un-unified,  unified  to  a  constant,  and  unified  to  another 
logic  variable.  The  process  LVar  records  these  states  by  storing  one  of  the  integers  -1, 0, 1  respectively  as  the 
first  component  of  its  record.  The  process  LVar  is  located  at  the  address  1.  The  act  of  reading  the  valne  of  I  is 
modeled  as  receiving  values  on  the  channel  I,  while  the  act  of  writing  on  I  is  modeled  as  sending  values  on  the 
channel  1.  A  logic  variable  is  at  first  in  a  un-unified  state.  This  is  shown  by  the  subterm  /[—I,  I,  i]  of  LVar  (I  i). 
The  process  trying  to  read  the  value  of  I  receives  a  triple  of  names  on  the  channel  I,  and  from  the  value  .of  the 
first  entity,  it  can  make  out  that  Hs  in  a  un-unified  state.  Thus  any  number  of  processes  can  concurrently  read 

On  the  other  hand  only  one  process  can  succeed  while  trying  to  unify  a  given  logic  variable  with  any  other 
entity.  Before  attempting  to  unify  a  logic  variable  it  is  necessary  to  ‘lock’  it  so  as  to  ensure  mutual  exclusion. 
This  IS  essential  in  order  to  avoid  circularities  in  the  data  representation.  Locking  a  logic  variable  /  is  achieved 
y  sending  a,  newly  created  channel  name  k  on  the  name  1.  The  channel  name  k  is  next  used  to  transmit  the 
eifiity  to  which  I  has  to  unified  and  also  the  code  which  represents  the  ‘sort’  information  regarding  the  entity, 
ihe  ^t  of  communicating  s  and  n  on  k  also  corresponds  to  one  of  the  ways  of  unlocking  1.  The  other  way  of 
unlocking  /  is  to  simply  send  a  synchronization  signal  k  without  transmitting  any  names  on  k.  1£  I  is  locked 
and  unlocked  again  without  unification,  then  it  returns  to  the  state  in  which  it  existed  prior  to  locking  This  is 
indicated  by  the  recursive  definition  of  LVaril,i).  On  the  other  hand,  if  unification  succeeds  then  the  behavior 
of  IS  forever  governed  by  the  sub-term  with  the  bang  operator,  namely  !l(s,n,i).  The  value  of  I  can  be  read 
forever  by  ^y  number  of  processes.  Any  further  attempts  to  unify  /  will  be  passed  on  to  the  entity  n  to  which 
<  has  already  been  unified  to. 


3.2  Translating  constants 

Natui  al  numbers  are  formally  translated  as  pi  processes.  The  translation  of  number  n  is  given  by  |[n| 
Note  that  the  format  of  the  encoding  is  consistent  with  that  of  logic  variables. 


!n[0,n, «]. 
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I  tellih  =  h)  ]s,f  = 
Tell{h,l2,s,f)  = 


Tell{li,h,  s,f) 
[h  =  h] 

(s. 


Prior ity{h,l2,  vp\,vp2). 
{pi.Unify{h,l2,s,f) 


+ 

P2.Unify{l2,lus,f) 

) 

) 

Priority{li,l2,pi,p2)  =  li{xi,X2,X3).  Traverse{x3,l2,pi,P2) 
Traverse{from,dest,pi,p2)  =  /rom(ai,Q2). 

[ai  =  z] 

(Pi. 

ai  (a,  6). 

[6  =  dest] 

(P2. 

Traverse{a,de^t,pi,p2) 

) 


Fig.  3.  Translation  of  ‘Tell’  action 


3.3  Translating  “ask” 

The  translation  of  “ask”  action  is  shown  in  Figure  2.  The  query  ask(li  —  h)  is  mapped  to  the  process 
Ask{h  ,l2,s,  f)  where  s  and  /  are  two  additional  channel  names  which  are  used  to  indicate  the  result  of  the  ask 
operation,  where  s  stands  for  ‘success’  and  /  for  ‘failure’.  The  process  Ask{h,l2,s,  f)  succeeds  immediately  if 
h  and  I2  denote  the  same  logic  variable;  otherwise  it  receives  the  triples  of  names  (si,  2:2, 3:3)  and  (wi,  102,103) 
on  the  channels  li  and  I2  respectively.  In  case  the  sorts  match  i.e.  xi  —  wi,  then  X2  and  W2  are  compared  for 
identity.  If  they  are  identical  then  the  ask  operation  succeeds,  as  indicated  by  s.  Else  the  situation  that  prevails 
is  as  follows:  h  and  I2  are  distinct  entities  of  the  same  sort.  If  they  refer  to  constants  then  the  ask  operation 
fails,  as  shown  by  /;  else  they  refer  to  other  logic  variables,  and  the  the  ask  operation  is  recursively  invoked  on 
the  entities  X2  and  W2  as  shown  by  the  subterm  Ask{x2,W2,s,  f)  where  the  same  channels  s  and  /  are  passed 
on  to  indicate  the  result  of  the  osfc  operation. 

3.4  Translating  “tell” 

The  translation  of  “tell”  action  is  shown  in  Figure  3.  The  query  =  I2)  is  mapped  to  the  process 

Tell{h,l2,s,f)  which  begins  by  invoking  the  process  Priority  in  order  to  determine  which  of  k  and  h  has 
greater  priority,  and  uses  such  information  to  execute  one  of  the  two  mutually  disjoint  choices. 

The  process  Priority{li,l2,pi,p2)  first  reads  the  state  of  the  logic  variable  li  and  then  invokes  the  process 
Traverse{x3,l2,pi,p2)  where  2:3  gives  the  index  of  k  in  the  linked  list  of  all  logic  variables  maintained  by 
OrderLVar.  The  process  Traverse  begins  accessing  the  list  by  indexing  into  the  element  which  points  to  li.  It 
then  traverses  the  list  until  it  can  find  I2  on  the  list,  or  until  it  reaches  the  beginning  of  the  list. 

In  case  h  is  encountered  during  the  traversal  of  the  list,  it  shows  that  h  occurs  earlier  than  h  on  the  list, 
thus  I2  has  greater  priority.  On  the  other  hand  if  the  beginning  of  the  list  is  reached  without  encountering  I2, 
then  li  has  greater  priority.  The  result  is  communicated  back  by  performing  either  pi  or  p2  as  the  case  may  be. 
The  process  T'eH(Ii,  ^2,  s, /)  then  invokes  the  appropriate  unification  routine. 

3.5  Translating  “unification” 

The  translation  of  “Unify”  operation  is  shown  in  Figure  4.  Unification  of  concurrent  logic  variables  is  achieved 
using  a  two-phase  locking  strategy.  In  the  process  Unify{li,l2,  s,  f  )  it  is  known  that  h  has  greater  priority  over 
h-  Thus  any  need  to  keep  li  and  I2  locked  at  the  same  time  is  executed  by  first  locking  li  and  only  when  this 
succeeds  I2  is  also  locked.  This  helps  in  preventing  deadlock  in  situations  where  there  are  multiple  instances  of 
the  Unify  process  trying  to  unify  the  same  pair  of  logic  variables. 
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Unify{h,l2,sJ)  =  [h:::^l2] 

{s,  _ 

iMt'ki]. 

Q2[vk2].  fei[l, h].  k2-  s 

-f- 

h{m,W2,ws). 

[wi  =0] 

(jfci[0,  n>2].s, 
ki-Tell(li,w2,s,f) 

) 

) 

+ 

h(xl,X2,Xi). 

[xi  =  0] 

(  (/2(t'A:2].fc2lO,  2:2].? 

“h 

l2iwi,W2,W3). 

[wi  =0] 

([2:2  =  W2] 

’  is,f), 

Tell{x2,W2,s,f) 

), 

TeU{x2,l2,s,f) 

) 

) 

) 


Fig.  4.  Translation  of  ‘Unification’ 


3.6  Ti-anslating  procedures  and  other  constructors 

The  translation  of  procedures  and  other  constructors  is  shown  in  Figure  5.  The  translation  of  procedures 

^ried"tS-teT  T  declarations  and  also  translating  procedure  invocations.  Procedure  declarations 
mapped  to  infinitely  replicating  resources,  which  can  make  any  number  of  copies  of  the  translations  of  the 
corresponding  procedure  bodies.  Procedure  invocations  are  mapped  to  requests  which  trigger  the  appropriate 

areWrirttrtf  L^ehhL^T^T''  ""  parameters.  Actual  parameters  in  procedure  invocations 

mLren  ?  or  constants.  In  particular,  other  procedures  axe  not  allowed  as 

^guments.  J^is  is  in  keeping  with  the  first-order  nature  of  CCP.  Further,  parameter  passing  is  by  reference. 
There  is  a  straight  forward  translation  of  all  the  other  process  constructs. 


4  Semantic  Correspondence 


The  following  theorem  establishes  that  our  embedding  is  semantics  preserving,  and  in  particular,  the  semantic 
function  maps  weak  reduction  congruence  of  ccp  processes  to  weak  barbed  congruence  of  pi  processes. 


Theorem  1  (Semantic  Correspondence).  For 

mantic  mappings  fFj,  fQ]  in  Pi.- 


any  two  CCP  processes  P,  Q,  and  their  corresponding 


se- 


2.  If  P  is  weak  reduction  congruent  to  Q  in  ccp,  then  [PJ  is  weak  barbed  congruent  to  fg]  in  Pi. 
Proof  Provided  in  [12]. 
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lP{y)  :  ->i|  p  =  !p(i/).|^l 
|P(k)|  p  =  p[x] 

|m/]s, /  =  s.O 

|Ai  -4  ^2!  s,f  =  (u  cont)  d^i]  cont,f  |  cont.lA2l  s,f) 

{Ai  ©  A'^  s,f  -  [All  s,f  +  [-4218,/ 

{Ai  II  ^2!  s,/ =  Uil  8,/ I  IA2I  s,/ 


Fig.  5.  Translations  of  Procedures  and  other  constructors 


5  Related  Work 

Related  research  may  be  classified  under  three  main  sub-headings: 

1.  Sequential  logic  programming  to  ir-Calculus:  Sequential  logic  programming  and  sequential  Prolog  may  be 
considered  as  special  cases  of  CCP.  Work  reported  in  [3, 13]  provide  translations  of  logic  variaibles,  unifica¬ 
tion,  and  features  of  Prolog  to  7r-calculus.  However,  these  papers  are  unencumbered  by  the  complexities  of 
concurrency  in  their  source  languages. 

2.  Variants  of  CCP  to  enhanced  Tr-calculus:  There  are  papers  [9, 17]  which  provide  an  embedding  from  either 
p-calculus  or  7-calculus  to  the  7r-calculus.  The  p-calculus  and  7-calculus  [17]  are  variants  of  CCP.  However 
the  embedding  proposed  by  these  papers  [9, 17]  require  the  support  of  extra  additions  to  the  primitives  of 
TT-calculus,  such  as  variables,  equations,  and  elimination  rules.  The  work  in  [19]  embeds  the  p-calculus  on 
the  fusion  calculus  [10],  which  is  a  generalisation  of  7r-calculus, 

3.  Variants  of  CCP  to  basic  -K-calculus:  The  work  of  Victor  and  Parrow  [18]  provides  an  embedding  from  the 
7-calculus  [17]  to  the  basic  (polyadic)  7r-calculus  without  the  need  for  any  additional  enhancements.  The 
version  of  the  7-calculus  that  they  deal  with,  contains  logic  variables,  equational  constraints,  and  a  form  of 
constraint  resolution  called  elimination.  However  their  proposal  is  inadequate,  since  their  translation  of  logic 
variables  leads  to  deadlocks  during  concurrent  update  operations  on  the  logic  variables.  Such  a  scenario  can 
be  constructed  as  follows:  In  their  construction,  equivalence  trees  of  Pi  processes  correspond  to  equivalent 
classes  of  logic  variables.  In  order  to  make  sure  that  the  equivalence  trees  do  not  become  circular,  certain 
conditions  are  imposed  on  the  pi  terms  that  correspond  to  the  logic  variables.  In  particular  when  a  logic 
variable  (say  x)  is  processing  an  ‘x  >  update’  request,  no  other  logic  variable  is  allowed  to  update  to  x.  This 
is  ensured  by  disabling  ‘x  >  value’  requests  during  update  sections,  and  vice  versa,  since  another  variable 
must  read  the  value  of  the  reference  it  is  updating  to.  Their  translation  does  indeed  take  measures  to 
prevent  deadlocks  when  x  is  told  to  update  to  itself  either  directly  or  indirectly.  However,  their  translation 
does  not  prevent  deadlocks  in  cases  where  two  distinct  logic  variables  are  trying  to  update  to  each  other 
concurrently.  For  example,  the  request  x  >  update(y)  in  parallel  with  the  request  y  >  update(s)  could  lead 
to  a  deadlock  (for  ever).  Further,  there  is  no  simple  way  of  modifying  their  translation  in  order  to  escape 
from  such  situations. 

In  contrast  with  the  other  works,  our  approach  gives  a  correct  translation  from  the  essential  features  of  CCP  to 
the  minimal  Pi  without  requiring  any  additional  enhancements. 

6  Conclusion 

In  the  design  space  of  models  of  mobile  computation,  CCP  and  PI  are  located  at  opposite  ends  of  the  spectrum. 
PI  is  based  on  the  message  passing  approach,  while  CCP  is  based  on  the  shared  memory  approach.  A  major 
difference  between  these  two  approaches  lies  in  the  extent  to  which  the  interaction  between  components  can 
affect  the  rest  of  the  system.  In  the  case  of  pi  the  effect  of  an  interaction  is  entirely  local  to  the  complementary 
pair  of  communicating  agents.  On  the  other  hand,  in  CCP  the  result  of  interactions  is  to  modify  a  global  state, 
which  could  affect  even  those  components  which  were  not  part  of  the  interaction.  We  have  thus  related  two 
major  paradigms  of  mobile  computation,  which  are  based  on  totally  orthogonal  primitives.  In  a  sense,  this  opens 
up  possibilities  of  exploring  new  paradigms  of  mobility,  which  use  a  judicial  mix  of  the  characteristics  of  CCP 
and  PI.  One  such  paradigm  is  the  fusion  calculus  [10].  The  study  of  such  formalisms  within  a  more  general 
framework,  would  surely  be  a  fruitful  direction  of  research  on  paradigms  of  mobility. 
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Abstract.  This  paper  describes  an  algebraic  structure  which  allows  to  define  an  abstract  structure  for 
'communication  in  distributed  systems.  Using  this  structure  we  introduce  an  equivalence  relation;  the 
quotient  induced  by  this  equivalence  relation  preserves  the  initial  algebraic  structure.  Our  results  can  give 
a  suitable  framework  to  study  communication  in  computer  networks,  complementary  to  process  algebras. 


1  Introduction 

The  aim  of  the  paper  is  to  find  a  class  of  structures  as  mathematical  abstractions  used  for  structural  aspects  of 
concurrent  communication  processes.  In  process  algebra  processes  are  usually  considered  as  terms.  We  treat  a 
process  considering  its  internal  structure  which  is  related  with  communication,  namely  its  ports  and  communi¬ 
cation  symmetries.  Our  approach  is  close  to  that  presented  in  [Ho]. 

First  we  define  in  an  abstract  way  how  two  processes  can  communicate  each  other  by  using  communication 
handles.  We  consider  mainly  correspondences  and  maps  of  suitable  handles  used  by  communicating  processes. 
The  basic  elements  of  our  approach  are  the  interface  ports  used  by  processes  for  interaction.  We  give  a  name- 
free  presentation  where  the  notion  of  symmetry  plays  an  essential  role.  Interacting  processes  assume  points  of 
interaction  called  ports.  Each  interaction  channel  is  determined  by  two  points  of  interaction.  Various  concurrent 
algebras  and  calculi  use  names  for  communicating  channels,  i.e.  they  use  names  for  the  corresponding  interaction 
points  which  determine  the  communication  channels.  This  fact  suggests  that  the  semantics  of  processes  depends 
on  names.  Here  we  “forget”  names,  but  still  keep  their  functionalities.  The  essence  of  the  functionality  of  channel 
names  is  to  determine  multiple  identities  and  to  represent  in  an  intelligible  way  how  we  relate  the  communication 
entities.  The  model  we  propose  works  with  a  concept  of  communication  internal  symmetry;  this  symmetry  is 
related  to  the  communication  channels  between  the  process  and  the  network.  Over  the  set  of  interaction  points 
given  by  these  communication  channels  we  may  define  a  permutation  group;  each  permutation  represents  an 
interchange  of  interaction  points  which  preserve  the  external  communication  capabilities  of  the  process.  In  this 
way  we  introduce  a  communication  structure  which  is  based  on  the  notions  of  process,  communication  channels, 
interaction  points  and  permutations.  These  structures  are  designed  to  make  easy  the  introduction  of  a  suitable 
notion  of  congruence,  and  then  a  suitable  notion  of  quotient.  Our  main  result  is  that  any  two  quotients  are 
isomorphic. 

2  Communication  Structures,  Correspondences,  Maps. 

Definition  1.  A  communication  structure  is  given  by  the  following  elements: 

(i)  V  ~  the  set  of  processes;  p,q,s,.. .  range  over  V; 

(a)  every  process  p  £  V  has  a  set  of  handles  H (p)  ; 

(Hi)  for  every  process  p  £  V  and  for  every  subset  K  C  H{p),  it  exists  a  permutation  subgroup  over  K  denoted 
hyS^^; 

(iv)  for  every  H  C  H'  C  H(p)  we  have  ; 

(a)  if  p  £  Sff,  and  pf h'\h  —  then  pf  h  e  S^, 

(b)  is  a  subgroup  in  S^,  (we  use  extension  by  identity  on 

The  set  H{p)  is  the  set  of  all  communication  points  of  p.  Permutations  of  describe  the  internal  symmetry 
of  p. 

Definition  2.  Let  V  and  Q  be  two  communication  structures;  &  correspondence  between  two  processes  p  £  P 
and  q  £  Q  is  a  triple  {S^,(p,Sjj,),  where  H  C  H{p),  H'  C  H{q)  and  cp  :  Sjj,  is  a  group  morphism.  We 

denote  by  d{P,  Q)  the  set  of  all  correspondences  between  processes  from  V  and  Q. 
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Definition  3.  LetV,  Q  andS  be  three  process  structures.  The  composition  of  correspondences  is  a  partial  binary 
operation  "o"  :  d{P,Q)  xd{Q,S)  d{P,S)  defined  by  where 

pEV,q£Q,s£S  andH  C  H{p),  H'  C  H{q),  H"  C  H{s). 


It  is  easy  to  prove  that  the  composition  of  correspondences  "o"  is  associative. 

Definition  4.  IfV  and  Q  are  two  communication  structures,  a  map  from  V  to  Q  is  a  set  of  correspondences 
P  Q  d{P,Q)  such  that  for  every  process  p  6  V,  and  every  subset  H  C  H{p),  there  exist  a  process  q  £  Q,  a  subset 
^  ^  wnd  a  correspondence  E  T,  and  they  are  unique.  We  denote  this  map  by  P  :P  — >  Q. 

If  P  :  P  -t  Q,  P'  :  Q  S  are  two  maps,  then  we  define  their  composition  P'  o  P  :  P  S  as  the  set  of  all 
possible  compositions  between  correspondences  from  P  and  P'-,  it  is  easy  to  see  that  the  composition  P'  oP  is 
also  a  map. 


Definition  5.  Let  P  be  a  communication  structure. 


(i)  the  identical  map  over  P,l-p  :P  -^P  is  the  set  {{S^,  id,  S^fj)  :  H  C  H{p)}. 

(ii)  a  map  P:P  Q  is  called  isomorphism  if  there  exists  another  map  P'  :Q-^P  such  that  PoP'  =  1q  and 

P'  oP  =  lp.  In  this  case  P'  is  called  the  inverse  map  of  P  and  is  denoted  by  P"-^ . 

3  p-translations  and  p-equi valences. 

Definition  6.  Let  P  be  a  communication  structure. 

(i)  for  two  given  processes p,q  E  P,  atranslation  fromp  to  q  is  a  triple  where  H  C  H{p),  H'  C  H{q) 

and  5  :  H  H'  is  a  one-to-one  function  (denoted  also  by  pu  qn'  or,  if  it  is  possible,  simply  by  6). 

(ii)  two  translations  pn  qn'  and  pa  q^,  from  p  to  q  are  called  equivalent  (we  denote  this  by  di  ~  62) 

if  we  have  two  permutations  p  E  S’fj  and  p'  E  S%,  such  that  Si  =  p'  o  62  o  p; 

(Hi)  a  p-translation  :  p  — over  the  communication  structure  P  is  a  family  3?  of  translations  (from  P  to 
P )  with  the  following  properties: 

-for  every  translation  d  e  3?,  i/d  ~  d',  then  S'  E  R,  and 
-  if  pH  ph  €  3?,  then  S  E  S^. 

The  relation  ~  defined  over  translations  is  an  equivalence  relation.  We  define  the  following  operations  over 
translations  and  p-translations: 

(1)  the  inverse  of  a  translation  pH  qn-  is  qn'  pn]  the  inverse  of  a  p-translation  3i  is  the  set 
:  d  e  5R}  denoted  by  3J-T 

(ii)  the  composition  of  two  translations  pn  i — >  qw  and  qn’  sh'‘  is  the  translation  pn  sh"  ;  the 
composition  of  two  p-translations  3?i  and  3?2  over  the  same  communication  structure  is  the  family  {di  o  d2  : 
di  G  3?i,d2  e  3?2}  (whenever  the  composition  is  possible),  and  it  is  denoted  SRi  o  3^2.  ‘ 

Lemma  1.  (i)  the  inverse  of  a  p-translation  is  also  a  p-translation; 

(ii)  the  composition  of  two  p-translations  over  the  same  structure  is  also  a  p-translation. 

Definition  7.  (i)  the  identical  p-translation  over  a  communication  structure  P,  denoted  by  idj?,  is  the  family 
{  Ph  e^  Ph  '■  P  EP,  H  C  H(p),  p  E  }  ; 

(ii)  a  p-translation  3?  defined  over  a  communication  structure  P  is  a  p-equivalence  if  it  is  reflexive  (idv  C  3?) 
symmetric  (1ft  ^  C  R),  and  transitive  (1fto3i  C  3JJ.  ’ 


4  Quotient  structure.  Isomorphism  theorem. 

Let  R  :  P  —Ephea  p-translation,  and  we  consider  the  set  p  =  {{p,H)  :pEP,HC  H{p)}-  for  the  sake 
o  simplicity,  we  use  the  notation  pn  instead  of  {p,H).  Then  we  define  the  binary  relation  «3{C  p  x  p  by 
PH  qw  if  and  only  if  there  exists  a  translation  pn  E^  q^  G  3i. 


Lemma  2.  is  an  equivalence  relation  over  p  if  and  only  if  5ft  is  a  p-equivalence. 
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We  will  denote  the  quotient  by  3?®^,  and  equivalence  class  of  ph  by  [pn].  Moreover,  we  choose  a  repre¬ 
sentative  from  every  equivalence  class;  for  each  such  a  choice,  we  can  build  a  structure  on  3?*^  in  the  following 
way: 

-  the  process  set  is  the  family  of  the  all  equivalence  classes  \ph]\ 

-  for  every  equivalence  class  [pn],  if  PH  is  the  representative  we  have  chosen  above,  then  we  define  H{\ph]) 
as  H  (which  is  included  in  i/(p)); 

-  if  [pif]  is  an  equivalence  class,  and  H'  C  H{\ph]),  the  corresponding  permutation  group  is  S^,  (of  our 
initial  communication  structure). 

Theorem  1.  The  structure  defined  above  on  3?’’^  is  a  communication  structure. 

Two  different  representative  choices  determine  different  structures  on  the  quotient  The  following  theorem 
shows  the  relationship  among  these  structures. 

Theorem  2.  Any  two  structures  determined  by  two  different  representative  choices  are  isomorphic  communi¬ 
cation  structures. 

Proof.  We  denote  by  3?*^  and  the  structures  determined  by  two  families  of  representatives  {p  iff  :  i  e  1} 

and  {qifji  :  z  G  /};  Pijj  ««  Qiff,  for  every  i  G  I.  Clearly,  we  have  a  translation  piff  qiff,  G  3i.  Let 
Hi  C  H{\piff])  =  H  and  H'l  =  Consider  now  pi  G  we  extend  pi  on  H  \  Hi  by  identity,  and 

we  obtain  p  e  S^.  Since  5~^,p  G  3i,  we  have  p'  =  Si  o  p  o  5i~^  G  3J;  this  implies  p'  G  Sj^,.  Therefore 
p'j  =  p'/h'i  €  We  define  (pi^^  :  —4  (fi^^  (pi)  =  p\;  is  a  group  morphism.  In  a  similar 

way  we  define  4’i^  ^  ^  show  that  ipi^  ^  is  a  group  morphism. 

The  family  P  =  {  :  i  £  I,  Hi  C  H  }  is  a.  map  from  3J~  to  3f'^' ,  and  P'  —  {  ipi^  ^  :  i  £  I ,  H[  G  H'  }  is 

a  map  from  3i'^’  to  3i^.  P'  is  the  inverse  map  of  P  :  <pi-^‘  o  ipP,  ^  —  idgu  and  ijji^  '■  o  idcfPi  . 

H'l 

5  Final  Remarks 

The  definition  of  correspondences  has  the  advantage  that  it  does  not  require  an  equivalence  relation  over 
correspondences.  The  correspondences  are  not  used  to  define  translations  and  p-translations  and  this  helps  us 
to  distinguish  between  maps  and  equivalences.  As  a  final  remark,  we  can  affirm  that  such  a  structure  reflects 
the  complexity  of  the  communication  along  the  computer  networks.  The  need  of  a  conceptual  and  formal 
framework  which  make  possible  the  study  of  network  communication  problems  and  properties  is  strongly  felt 
(in  our  opinion).  This  paper  is  a  step  to  such  a  suitable  framework.  It  defines  and  studies  the  communication 
structures,  formal  tools  which  are  complementary  to  process  algebras,  and  can  describe,  analyze,  and  possibly 
improve  network  distributed  systems. 
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Abstract.  The  present  work  is  oriented  on  the  description  of  the  elementary  educational  informatics  based 
on  the  programming  support  environment.  The  environment  structure  and  its  components  developed  on 
national  languages  are  being  investigated.  The  problems  of  language  tools  and  program  development  system 
as  well  as  computer  support  and  informatics  systems  are  being  studied. 


1  Introduction 


Educational  informatics  provides  elementary  computer  knowledge  []].  This  course  should  be  supplied  with  a 
special  teaching  conception  (model).  Educational  informatics  can  be  considered  as  an  elementary  subject  (such 
as  mathematics,  physics,  biology),  but  it  has  two  peculiarities  which  should  be  taken  into  consideration:  ^ 

1.  Methodological  and  technological  basis  and  methods  of  teaching  are  being  rapidly  changed; 

2.  It  needs  constant  support  with  special  technical,  language  and  programming  means.  That’s  why  the  cho- 

ptculiarities^  implementation  of  its  program  language  support  should  take  into  account  these 

We  present  one  of  the  educational  informatics  models  and  introduce  the  ways  of  developing  language  tools 
and  ^teins  aimed  to  support  this  model.  The  paper  consists  of  three  parts  and  a  conclusira.  The 

i  description  of  informatics  teaching  model.  The  peculiarities  of  development  of  complex 
components  are  introduced  in  the  second  and  third  parts. 


2  Informatics  Teaching  Model 

At  present  different  methods  are  used  in  conceptual  development  of  informatics  teaching.  One  of  them  is  the 

usage  of  the  vangu^ard  style  directed  to  the  study  of  logic-mathematical  base  of  algorithmization  and  elements  of 

Sbig  fivrpScfpi®' 

2.  Learners’  qualification.  The  main  accent  is  made  on  teaching  algorithmic^  and  programming- 

■  t  altfrib  structures  and  typical  programming  methods.  Constant  interconnection  be- 

is  showi  programming  is  demonstrated,  and  ’’smooth”  transition  from  one  level  to  another 

4.  Usage  of  the  native  language.  Teaching  is  aimed  at  the  learner’s  native  language  with  the  use  of  language 

program  means  and  technological  methods  based  on  national  interface;  language- 

5.  Multinational  tools.  Language,  program  and  technological  means  of  study  are  developed  with  account  of 

their  adaptation  to  various  lexicons.  vitn  account  ot 


The  functional  purpose  of  such  a  method  and  language  tools  and  programming 
of  the  informatics  teaching  model  for  senior  pupils  and  junior  students. 


systems  is 


to  satisfy  needs 
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3  Language  Tools 

Language  tools  contain  a  special  language  used  for  the  description  of  algorithms  and  a  programming  language 
of  higher  level. 

Algorithmic  Language.  A  special  algorithmic  language  (SAL)  [2]  has  chosen  as  the  algorithmic  language. 
This  language  has  different  notations,  close  to  the  natural  language,  algorithms  in  it  can  be  written  and  read 
as  a  usual  text  and,  what  is  more,  the  study  of  this  language  will  help  one  to  get  more  profound  knowledge 
of  any  programming  language  in  the  future.  Another  important  aspect  of  SAL  is  that  its  structure  is  close 
to  algorithmic  mentality  of  a  learner,  it  has  no  goto  command,  which  satisfies  the  reguirements  of  structural 
construction,  and  there  are  no  details  connected  with  the  computer  device. 

For  easy  usage  and  realization  needs,  some  changes  and  additions  were  made  to  SAL,  such  as  introduction  of 
two  new  commands  (input  and  output)  which  are  used  for  intermediate  data  input  and  output;  specification 
of  dynamic  tables;  the  usage  of  key  words  without  underlining  and  linear  notation  of  expressions,  etc.,  as  in 
modern  programming  languages  (PL). 

Programming  Language.  We  have  chosen  Pascal/P  [3]  which  has  the  basic  Russian  notation  of  Standard 
Pascal  [4].  In  general,  we  can  state  two  main  factors  having  effect  on  defining  the  language  tools. 

The  first  is  the  choice  of  the  minimum  necessary  structures  sufficient  for  initial  study  of  algorithms  and 
programming  and  traditional  for  many  modern  languages.  Some  data  types,  as  well  as  statements  and  special 
Pascal  functions,  were  excluded.  The  label,  datatype  set,  variant  record,  goto  statement,  cycle  statements 
of  the  type  for...  downto  and  repeat. ..until  were  reduced  and  the  procedures  get(/)  and  put(/)  of  the 
processing  file  /  were  not  used.  For  practical  needs  data  types  string  and  string[n]  were  included  into  the 
language,  as  well  as  two  new  procedures  of  file  processing  (Close  and  Assign)  of  the  programming  language 
Turbo  Pascal.  . 

The  second  factor  is  connected  with  the  national  lexicons  of  the  language  means.  That  is  why  they  were 
localized  on  the  other  languages  (Russian,  Uzbek, Tajik)  on  the  basis  of  Cyrillic  and  Latin  graphics.  Thus, 
algorithmics  and  programming  should  be  studied  on  the  basis  of  the  native  language  of  the  learner,  and  input 
languages  of  the  system  should  have  modifiable  lexical  structure. 

4  Programming  Systems 

The  programming  complex  consists  of  a  specialized  system  on  the  basis  of  SAL  and  a  programming  system 
(PS)  with  the  localized  input  language  Pascal.  The  first  system  is  used  for  computer  support  of  the  algorithmic 
course,  and  PS,  for  study  of  fundamentals  of  programming.  Each  of  these  systems  are  developed  in  the  form 
of  an  integrated  environment  with  common  components.  The  environment  is  initially  produced  to  support  a 
definite  style  of  constructing  and  debugging  of  algorithms  (programs) .  Its  components  are  the  working  window 
with  the  main  menu,  editor,  compiler,  help  subsystem  and  data  base  (DB).  Let  us  briefly  discuss  the  peculiarities 
of  the  teaching  environment  and  its  components. 

The  Program  Construction  and  Debugging  Style.  The  environment  is  oriented  at  the  style  of  struc¬ 
tured  construction  on  the  basis  of  structure  editing  algorithms.  It  is  also  supplied  with  the  debugging  display 
and  program  running  [5].  The  structural  construction  in  educational  informatics  gives  the  following  advantages: 

a)  This  type  of  construction  is  closer  to  operation  mentality  of  a  man.  It  gives  the  possibility  of  more 
adequate  description  of  typical  processes  in  the  application  area  of  the  task  with  the  help  of  definite  integral 
constructions  of  the  programming  language; 

b)  It  combines  the  ’’strict”  requirements  to  the  structural  and  usual  types  of  string  editing.  The  first  of  them 
puts  limitations  on  the  user  actions  and  is  useful  in  training  the  beginners; 

c)  The  program  becomes  an  active  object  at  the  very  beginning  and  within  the  process  of  its  construction. 
Partially,  it  is  ready  for  use  even  not  being  completed.  This  provides  the  program  check  out  which  step  by  step 
ensures  the  programmer  in  correctness  of  his  choice  and  actions. 

Another  important  mechanism  of  the  education  process  is  visualization  of  debugging  and  running  of  a 
program.  To  display  the  process  of  running,  the  output  facilities  should  be  realized  in  the  system  so  that  the 
text  of  the  original  program  should  be  presented  on  display  with  its  increased  detailed  block-scheme,  with 
underlined  and  coloured  areas  of  constructions’  domains  and  keywords  of  the  language,  and  values  of  variables 
being  indicated  in  the  control  points. 

Working  Panel  and  Main  Menu  Console.  It  is  known  that  the  interactive  mode  is  the  basic  in  the 
training  systems.  It  provides  interconnection  with  the  pupil.  The  program  start  is  followed  by  displaying  the 
main  menu  at  the  top  of  the  window.  Menu  contains  options:  File,  Editing,  Translation,  Lexics  —  each  can 
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have  vertical  suboptions.  In  the  lower  part  of  the  display  there  is  a  prompting  string  showing  the  coincidence 
between  the  functional  keyboards  and  actions.  Using  the  option  Lexic[suboption],  a  learner  chooses  the  notation 
for  writting  algorithms  on  the  basis  of  SAL  (Pascal  program)  and  lexicon  of  the  communication  system.  Further 
work  is  fullfilled  in  this  Language  environment. 

Editor.  The  embedded  system  editor  has  two  operation  modes  —  textual  and  structural.  The  structural 
mode  is  the  main  one,  since  in  the  process  of  studying  PL  much  attention  is  given  to  its  syntactical  constructions 
and  rules.  Editor  has  both  traditional  and  specialized  operations  with  texts  in  the  structural  mode,  such  as 
call  of  language  constructions  which  are  kept  in  the  form  of  ’’ready-made”  pictures,  transformation  of  the 
source  program  text  into  an  abstract  syntactic  tree  (AST)  and  vice  versa,  reorganization  of  AST,  recognition 
of  elementary  errors  and  output  information  on  them,  creation  and  modification  of  pictures.  At  first,  the 
pictures  (general  structure  of  algorithms  in  SAL  and  of  Pascal  programs,  program  items,  commands,  statements, 
additional  algorithms  and  subprograms)  are  kept  in  the  data  base  and  called  when  needed  and  after  the 
processing,  "loaded”  ("hung”)  in  a  definite  place  of  the  abstract  tree. 

For  example,  the  construction  if  (condition)  then  (statementl)  else  (statement2);  are  entirely  produced 
on  display,  while  the  parts  put  into  brackets  are  easily  deleted  and  their  place  is  taken  by  real  constructions. 

Thus,  this  principle  of  structural  editing  gives  us  the  possibility  of  program  check  at  each  step  of  the  process 
of  its  development,  being  useful  for  the  learner  and  preventing  him  from  "making  errors” . 

Coinpiler.  The  specialized  translators  of  the  system  on  the  basis  of  SAL  and  PS  with  Pascal  input  language 
are  developed  m  the  form  of  an  interpreter.  This  method  is  used  to  simplify  its  implementation  and  possesses  the 
following  peculiarities.  The  interpreter  opens  the  perspective  of  easy  process-projecting  management,  debugging 
and  visualization  of  programs  [6].  Using  the  interactive  mode,  we  can  write,  check  and  run  programs,  within 
the  interpreter.  Errors  can  be  easily  corrected.  We  should  not  go  back  to  editor  and  compile  the  program 
again.  Structural  construction  and  editing  [7]  provides  the  intermediate  representation  and  interpretation  of 
mcompleted  programs.  Programming  systems  can  be  used  for  educational  purpose  and  are  not  aimed  to  solve 
the  tasks  which  require  immediate  actions. 


Help  Subsystem  and  Data,  Base  System.  DB  is  developed  on  the  basis  of  the  electronic  textbook 
Ideology.  It  is  supposed  to  keep  the  structural  information:  theoretical,  practical  and  methodological  materials 
(glossaries  containing  the  basic  notions  and  terms  of  input  language,  the  set  of  type  schemes,  demonstration 
aJgOTrthms  and  programs,  as  well  as  many  tests  aimed  to  control  and  evaluate  the  trainer’s  knowledge) 

The  Data  base  of  environment  is  organized  and  kept  in  the  form  of  a  hypertext.  The  data  base  files  contain 
texts  of  the  mam  and  intermediate  representation  programs,  educational  texts  and  additional  information 
connected  with  a  definite  lexicon.  The  support  of  construction  and  functioning  of  the  components  of  the  help 
subsystem  and  the  data  base  is  fulfilled  by  a  separate  tool  system.  It  contains  the  set  of  special  operations 
working  with  the  hypertext,  information  input,  processing,  and  output  in  the  DB  system. 


5  Conclusion 

The  educational  model  for  studying  informatics  is  discussed  in  this  work,  as  well  as  the  questions  of  the  language 
tools  and  programming  system  development  intended  to  support  this  model.  The  general  strategy  of  teaching 
IS  based  on  advanced  learning  of  algorithmics  and  elements  of  programming  on  the  basis  of  a  native  language 

®  on  its  components  including  the  language  and  program  facilities 

and  hardware  support  has  been  defined. 
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Abstract.  We  consider  systems  of  cooperating  logic  programs  which  generalize  dynamic  deductive  data¬ 
bases  (DDDBs)  from  [1,2].  Some  properties  of  the  system  behavior  are  defined  which  ensure  an  infinite 
steady  life  of  the  system.  Decision  problems  for  these  properties  of  cooperating  productional  logic  programs 
are  investigated.  It  is  shown  that  these  problems  are  reducible  to  the  satisfiability  problem  for  the  propo¬ 
sitional  temporal  logic  of  branching  time.  It  follows  that  stability  problems  for  cooperating  productional 
logic  programs  are  decidable  with  exponential  time  complexity. 


1  Introduction 

In  this  paper  we  consider  a  logical  approach  to  the  mathematical  analysis  of  the  behavior  of  interactive  discrete 
dynamic  systems.  A  state  of  a  dynamic  system  is  represented  by  a  data  base  state  {DB  state),  i.e.  a  finite  set 
of  facts.  The  behavior  of  the  system  is  determined  by  actions  of  a  set  of  logical  programs  which  update  DB 
states.  These  actions  generate  a  set  of  possible  trajectories  of  the  system,  i.e.  sequences  of  DB  states.  Different 
requirements  on  the  system  behavior  can  be  defined  in  terms  of  conditions  which  should  be  satisfied  by  the  set 
of  trajectories.  Here  we  consider  only  one  of  interesting  kinds  of  the  behavior  properties  which  are  expressible 
in  such  terms,  namely,  the  stability  property  of  the  system.  Moreover,  we  limit  Our  consideration  by  the  case 
when  any  system  B  consists  of  n  -f  1  (in  general,  nondeterministic)  logic  programs,  a  master  MP  and  a  set 
of  slaves  SP  =<  SPi,  ...,SPn  >,  which  work  over  a  (finite  dynamic)  database  5  ,  updating  states  of  S  in 
turn:  on  every  odd  step  slave  programs  concurrently  change  the  current  database  state,  and  on  even  steps  the 
master  program  updates  the  database  state  with  the  aim  of  restoring  integrity  constraints  possibly  violated  by 
the  slaves  in  the  previous  step.  This  notion  of  cooperating  (symbiotic)  logic  programs  generalizes  the  notion  of 
dynamic  deductive  databases  with  external  updates  from  [1,2]. 

The  binary  relation  on  DB  states  induced  by  the  updates  executed  by  the  set  LP  of  logic  programs 
LPi, ...,  LPn  we  denote  by  \-lp  (in  this  paper  we  use  only  sets  LP  defining  total  relations  \-lp  )■  Then  local 
behavior  of  the  system  B  in  the  current  state  £o  is  described  as  one  interaction  of  SP  and  MP  applied 
to  this  state,  i.e.  as  the  sequence  of  two  updates  So  ^sp  S[  ^mp  S\.  Normally,  one  should  distinguish 
between  acceptable  and  not  acceptable  interactions,  depending  on  a  criterion  of  admissibility  of  system  states. 
Each  acceptable  interaction  applies  to  an  admissible  state  So  and  yields  an  admissible  state  S\.  However,  the 
intermediate  state  S[  may  in  general  be  inadmissible,  in  which  case  the  reaction  of  MP  compensates  for  the 
destroying  actions  of  SP  .  We  represent  the  admissibility  criterion  by  an  integrity  constraint  (IC)  expressed  by 
a  formula  over  DB  states.  In  terms  of  the  IC  the  acceptability  of  the  interaction  is  expressed  as  follows;  the 

*  This  work  was  sponsored  by  the  Russian  Fundamental  Studies  Foundation  (Grants  97-01-00973  and  98-01-  00204). 
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interaction  of  the  form  above  is  acceptable  if  N  ^  Si  |=  Thus,  the  system  B  representing  the 
interactive  discrete  dynamic  system  has  in  fact  the  form  <  MP,  SP  =<  SPi,...,SPn  >,  ^  >,  and  its  local 
behavior  is  expressed  in  terms  of  acceptable  interactions. 

Global  behavior  of  the  system  in  current  state  Sq  is  represented  by  sequences  of  interactions  starting  in 
So  which  we  call  trajectories 

^0  ^SP  S[  \-MP  Si  I-5P  S2  \-MP  £2  ... 

The  infinite  acceptable  trajectories  represent  the  stable  behavior  of  the  system:  any  possible  destro}dng  actions 
of  the  slave  programs  SP  are  compensated  by  some  actions  of  the  master  program  MP  along  all  the 
trajectory.  Such  trajectories  are  called  stable. 

Trajectories  of  the  system  B  form  a  tree  T(So)  with  the  root  Sq.  A  number  of  natural  properties  of 
interactive  behavior  of  5  in  a  given  DB  state  can  be  formalized  in  terms  of  this  tree,  in  particular,  different 
kinds  of  stability. 

Definition  1  Let  ^1,(52  £  {V,3}.  Then  B  is  Qi <52 -stable  in  DB  state  So  if  in  the  tree  T{So)  there  is  a 
QiQ2-subtree  in  which  all  branches  are  infinite  stable  trajectories.  ^ 

One  of  natural  questions  connected  with  these  notions  is  to  consider  algorithmic  decidability  of  the  stability.  Of 
course,  in  general  case  these  problems  are  undecidable.  In  [1,2]  some  classes  of  logic  programs  were  distinguished 
for  which  the  stability  problem  is  decidable.  But  only  one  slave  was  allowed  there,  and  a  very  simple  kind  of 
updates  was  considered  as  possible  actions  of  masters.  Here  we  consider  more  general  case  when  SP  is 
represented  by  a  set  of  working  in  parallel  programs  belonging  to  the  same  class  as  MP.  Because  of  space 
limitations  we  present  here  only  results  for  the  case  when  programs  MP  and  SP  belong  to  the  class  GPROD 
of  ground  productional  logic  programs  with  updates.  We  show  that  for  the  cooperative  systems  of  this  class 
the  decision  problems  for  stability  are  decidable  and  have  the  same  decision  complexity  as  for  corresponding 
problems  in  [1,2].  To  prove  our  results  we  show  that  the  variants  of  stability  problem  which  are  considered  here 
are  reducible  to  the  satisfiability  problem  for  a  variant  of  the  propositional  logic  of  branching  time.  Moreover, 
for  33  -stability  this  reduction  is  simultaneously  a  reduction  to  satisfiability  problem  for  the  logic  of  linear 
time.  As  a  corollary  we  obtain  that  results  on  polynomial  space  and  exponential  time  complexity  of  stability 
and  homeostaticity  problem  for  GPROD  from  [1,2]  are  generalized  to  systems  of  cooperating  programs  from 
GPROD.  Moreover,  we  note  that  some  lower  bounds  in  [1,2]  can  be  improved.  Namely,  results  on  EXPTIME- 
hardness  of  the  stability  problem  can  be  complemented  by  lower  bound  of  time  complexity. 

2  Basic  Notions  and  Definitions 

2.1  Productional  logic  programs 

We  consider  productional  logic  programs  with  updates  in  a  signature  S  consisting  of  a  set  of  constants  C 
and  a  set  of  predicate  symbols  Pr .  Let  H  denote  the  Herbrand  base  over  S.  A  productional  logic  program 
consists  of  clauses  of  following  form: 

TT  :  Coni&z...^Conk  =>  Acti,  ...,Act,n 

Each  Coui  {elementary  condition)  is  either  a  ground  atom  in  H  or  its  negation.  Each  Actj  {action)  is  one  of 
elementary  updates  insert{A),  delete{A)  where,  A  G  H.  For  simplicity  we  assume  that  there  are  no  conflicts 
in  application  of  actions,  i.e.  there  are  simultaneously  no  Actj  =  insert{A)  and  Acti  -  delete{A) 

A  data  base  (DB)  state  f  is  a  finite  subset  of  the  Herbrand  base  H.  The  production  tt  is  applicable  to  a 
DB  state  S  iff  for  every  l<i<k  Com  €  S  if  Com  is  a  ground  atom  and  Coui  ^  S  if  Com  is  a  negated 
ground  atom.  Let  tt  -<  tti,  ...,  7r„  >  be  a  set  of  productions.  The  simultaneous  application  of  these  productions 
to  a  state  S  can  be  defined  in  different  ways.  We  choose  here  the  following  one.  If  there  is  a  production  m  not 
applicable  to  S  then  7r_  is  not  applicable  to  L.  In  other  case  the  result  n{S)  of  simultaneous  application  of 
productions  tt  to  L  is  defined  as  a  DB  state  Si  obtained  from  S  by  adding  all  atoms  A  such  that  there 
is  a  production  m  e  tt  whose  action  includes  insert{A)  and  by  deleting  all  atoms  A  such  that  there  is  a 
production  m  G  tt  whose  action  includes  delete{A).  When  for  some  atom  A  there  are  two  productions  in  tt  one 
o  which  wants  to  insert  A  and  the  another  wants  to  delete  it,  then  A  does  not  change,  i.e.  A  G  Li  A  G  L.  (Of 

'  We  omit  here  the  straighforward  definition  of  Qig2 -subtrees,  E.g.,  V3  -subtree  Tt  of  T  has  the  following  properties: 
if  a  node  N  belongs  to  an  even  level  of  Ti  ,  then  all  successors  of  N  in  T  are  also  successors  of  N  in  Ti  and 
any  node  belonging  to  an  odd  level  of  Ti  has  at  least  one  successor  (from  T  ). 
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course  another  strategies  of  conflict  resolution  are  possible  as  well,  e.g.  by  some  kind  of  priority  of  programs.) 
So,  the  set  of  productions  tt  defines  an  update  relation  on  the  set  of  all  DB  state's:  £  iff  £i  =  Tr(£). 
The  update  relation  induced  by  a  set  of  productional  logic  programs  LP  =<  LPi,  ...,LPn  >  is  defined 
as 

^LP  bl{n'|jr=::<7ri,...,7r„>,7ri6iPi}  bjr  ■ 

We  consider  as  integrity  constraints  (ICs)  quantifier-free  first  order  formulas  over  S.  We  say  that  a  DB 
state  £  satisfies  an  IC  #  iff  f  |= 

2.2  Propositional  Temporal  Logic 

We  use  the  following  variant  of  propositional  logic  of  branching  time  (BPTL).  It  differs  from  the  logics  CTL 
and  CTL*  considered  in  the  survey  [3]  by  presence  of  the  past  temporal  operator  VT  (”in  the  previous  state”), 
though  it  is  simpler  in  other  respects;  it  does  not  contain  complex  temporal  operators  of  the  kind  VF.  CTL-like 
logics  with  past  temporal  operators  were  considered  in  [4]  and  [5].  The  temporal  structure  used  in  BPTL  is 
tree-like  (branching  forwards  and  linear  backwards).  Such  variant  of  the  time  structure  is  also  considered  in  [5] 
aihong  other  variants  (the  time  structure  used  in  [4]  is  branching  backwards  as  well  as  forwards).  Other  more 
general  than  BPTL  systems  can  be  found  in  the  area  of  the  propositional  dynamic  logics. 

The  formulas  of  BPTL  are  constructed  from  propositional  variables  by  using  the  Boolean  connectives  and 
temporal  operators  VX,  VF  and  VG  (operators  3J\:,  3Fand  3F  are  expressed  as  -iVX-., -.VF-i  and  -■VG-' , 
respectively). 

Models  of  BPTL  have  the  form  <  T,  tt  >  where  T  is  an  infinite  tree  with  branches  of  the  height  cj  ,  and 

JT  assigns  to  any  node  s  of  T  a  set  of  propositional  variables  satisfied  on  s  (as  usual  we  write  s  [=  p  instead 

of  p  e  7r(s)  ).  The  relation  \=  is  extended  to  all  the  formulas  of  BPTL  in  the  following  Way; 
semantics  of  boolean  connectives  is  defined  as  usual; 
s  1=  MX  p  iff  s'  1=  p  for  all  sons  s'  of  s; 

s  1=  VF  p  iff  s'  t=  p  if  s  is  not  the  root  of  T  and  s'  is  the  predecessor  of  s  (if  s  is  the  root  we  can 

assume  s  |=  VF  p  for  any  formula  p  ); 

s  f=  VGp  iff  s'  1=  p  for  all  nodes  s'  of  the  forward  paths  beginning  with  s  . 

According  to  the  definition  above  3Fp  means  ’’there  exists  the  predecessor  s'  of  s  such  that  s'  [=  p  ” 
(the  meaning  of  other  operators  is  also  clear) . 

The  given  above  version  of  semantics  for  BPTL  supposes  that  time  structure  is  branching  forwards  and 
linear  backwards.  Another  variant  of  semantics  for  BPTL  assumes  that  time  is  linear  forwards,  too. 

3  Reduction  of  Stability  to  BPTL 

In  this  section  we  construct  for  a  system  of  cooperating  logic  programs  B  -<  MP,  SP  ~<  SPi, SPn  >,  ^  > 
and  DB  state  £  BPTL-formulas  representing  Qj (52- stability  of  B  in  £.  To  simplify  notations  we  suppose  that 
n  =  2.  Let  MP  be  the  productional  logic  program 
fi~>updi 

fm  ^  'apdynt 

and  let  5Fi  be  the  productional  logic  program 

/ii->upalii 
fln\  ^  ^pdinj , 

and  SP2  be  the  productional  logic  program 
f2i->upd2i  - 

f  2n2  ^  ^pd2n2 ) 

where  are  conditions,  updij  are  updates. 

Any  DB  state  £  can  be  described  statically  as  conjunction  Conj{£^  of  (positive  ground)  atoms  occurring 
in  £  .  But  to  reflect  changes  of  states  caused  by  actions  of  MP,  5Pi  and  SP2  we  should  in  following  to 
take  into  account  also  some  negative  atoms.  So,  with  any  DB  state  £’ and  logic  programs  MP,  SPi,  SP2  we 
connect  the  formula  s{£)  which  is  conjunction  of  Conj{£)  and  negations  of  ground  atoms  occurring  in  MP 
SPi  or  SP2  but  not  in  £■.  ’ 
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Note  that  in  fact  we  can  consider  ground  atoms  as  propositional  letters.  In  what  follows  E  will  denote  the 
set  of  propositional  letters  which  occur  in  MP,  SPi,  SP2. 

For  any  update  r/pd  which  inserts  Ui, a,  ,  deletes  61,..., 6,  and  leaves  invariant  we  introduce 

a  formula  U PD  with  the  intended  meaning: 

s  \=  UPD  iff  the  following  is  true;  for  any  €  the  formula  s(5)  is  satisfied  in  s  iff  there  exists  a  DB  state  S' 
such  that  S  is  obtained  by  applying  upd  to  S'  and  s{S')  is  satisfied  in  the  state  s'  of  T  previous  to  s 
needed, too) 

UPDhastheform  AZi  =  ^Fci)  A  A-=i  Qi  A  A^i  -'h- 

For  any  x  e  E  we  introduce  new  variables  x~,x'^.  Using  these  variables  we  introduce  two  variants  of  UPD  : 
UPD'  =  Ai=i  (ci  =  3Y a)  A  ALi  {at  A  a*)  A  ALi  (K  A  -‘k). 

UPD"  -  A  -.a;-)  A  AI^,  ^  3Fc,) 

A  ALi((-’3ya^  fli)  A  (auar -4  (o^  =  3K3Fai))) 

Ai=i  -^bi)  A  (3F6t  ^  {bi  =  3Y3Ybi))). 

Q  .  UPD'  and  UPD"  are  used  below  to  simulate  parallel  executions  of  productions  from  S Pi  and 

0F2  ;  the  variables  x  and  x  in  them  are  used  to  store  the  information  for  the  conflict  resolution. 

Let  Q  be  a  new  propositional  variable.  Then  the  formula  EVEN  of  the  form 

Q  A\/G  {Q {VX -n  Q  A\/X  VX  Q)) 

expresses  tte  property  ”  Q  is  true  exactly  on  the  states  in' even  levels  of  T”.  A  somewhat  more  complicate 
formula  I  HIRD  (using  some  axillary  propositional  letter)  expresses  the  property  ”  Q  is  true  exactly  on  the 
states  in  any  third  level  of  T  ”. 

Let  Safety  denote  the  formula 
THIRD  AVG  {Q 

It  is  obvious  that  if  this  formula  is  satisfied  on  the  root  of  T  then  in  all  states  at  any  third  level  of  T  inteeritv 
constraint  ^  is  satisfied.  ^  ^ 

Now  we  are  ready  to  write  out  the  formulas  which  show  reducibility  of  the  stability  problems  for  the 
cooperating  logic  programs  to  the  satisfiability  problem  for  BPTL.  constraint  when  the  slave  of  subformulas  to 

(33)  :  B  =<  MP ,  <  SPi,Sp2  >,<f  >  is  33-  stable  in  S 
iff  the  formula 

^  VE.  (/..  A  axiUPiy,,  a  VE.Prfe  a  bxiupds,  a  v."L.  (A  a  3xuPD,))m 

Remark.  For  this  formula  the  linear  and  branching  time  satisfiability  coincide, 
only  fire 

(V3):  B=<  MP,<  SPi,SP2>,^>  is  V3-stable  in  S 
iff  the  formula 

V"  0  VE,/hAV2./mAAE,(A.  -4  3X(1/PD;,  A  A'iiOVA,  ^  3X(UPD"^f. 

Vjfe=i(/fc  A3XI7P£)fc))))))  is  satisfiable.  ’  j  v  2j 

Similar  formulas  can  be  given  for  the  W  -stability  and  the  3V  -stability. 

Remark  In  fact,  using  the  past  operators  in  these  formulas  can  be  avoided.  For  the  33  -stability  it  is 
rather  straightforward  (using  the  linear  time  logic)  and  does  not  increase  the  size  of  the  corresponding  formulas 
But  for  the  case  of  V3-stability  the  branching  structure  of  the  time  is  essential.  It  seems  that  in  this  case  the 
description  of  updates  without  using  the  past  operator  needs  to  explicitly  consider  all  the  DB  states,  but  it 
leads  to  the  exponential  increasing  of  the  formula  size. 

Note  that  ^1  these  reductions  have  polynomial  complexity.  In  general,  the  reduction  formulas  have  the  poly- 

f  ?  P'^^Srams.  So,  if  we  use  the  exponential  time  dedsion 

g  t  m  for  BPTL  (such  algorithms  can  be  obtained  by  easy  adapting  the  known  algorithms  for  different 
proposition^  or  dynamic  logics,  e.g.  from  [6])  we  obtain  for  the  stability  problems  an  upper  bound 

comp  exity  which  has  the  form  of  an  exponential  on  a  polynomial.  However,  we  can  obtain  some  more  exact 
complexity  bound  since  the  complexity  of  the  satisfiability  problem  for  BPTL  is  exponential  respectively  to  the 
?  subformulas  of  the  formula  considered  (not  to  the  length  of  the  formula),  and  it  is  easy  to  see  that 

So!  ^brai!  to  folZtag'° 
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Theorem  1.  (i)  The  QxQ^-stability  problem  for  cooperating  programs  in  GPROD  with  quantifier-free  in¬ 
tegrity  constraints  is  decidable  in  exponential  time  for  any  Qi,Q2  G  {3,V}  ; 

(ii)  The  BB-stability  problem  for  the  same  classes  of  programs  and  integrity  constraints  is  decidable  in 
polynomial  space. 

The  point  (ii)  is  obtained  using  reduction  to  the  linear  time  logic  (see  remark  above)  for  which  there  exists 
an  algorithm  with  polynomial  space  complexity  (see  [3]). 
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Abstract.  The  rule-based  paradigm  for  knowledge  representation  appears  in  many  disguises  within  com¬ 
puter  science.  In  this  paper  we  address  special  issues  which  arise  when  the  rule-based  programming 
paradigm  is  employed  in  the  development  of  reactive  systems.  We  begin  by  presenting  a  rule-based  language 
RL  which  has  emerged  while  developing  intelligent  cruise  control  systems.  We  define,  a  desired  declarative 
semantics  and  correctnep  criteria  for  rule-based  programs  which  respect  causality,  synchrony  assump¬ 
tion  and  desired  determinism.  Two  alternative  approaches  are  proposed  to  analyze  RL  programs.  Both 
approaches  build  upon  static  checks  of  a  rule-based  program.  In  the  first  approach  we  accept  programs 
which  are  correct  with  respect  to  a  constructive  semantics  while  in  the  second  approach,  a  stratification 
check  is  imposed.  The  combination  of  rules  and  reactive  behaviour,  together  with  a  formal  analysis  of  this 
behaviour  is  the  main  contribution  of  our  work. 


1  Overview 


The  rule-based  paradigm  for  knowledge  representation  appears  in  many  disguises  within  computer  science.  Lan¬ 
guage  issues  related  to  this  paradigm  appear  in  production  systems  [3],  parallel  program  design  (e.g.  Unity  [2]) 
default  reasoning  within  AI  [9],  logic  programming  [1],  rewriting  [7],  active  and  deductive  databases  [41,  and 
logics  for  action  and  change  [15]. 

Our  work  combines  results  from  the  three  areas  of  rule-based  knowledge  representation,  reactive  systems  [11 
6j,  and  propamming  language  semantics.  The  combination  of  rules  and  reactive  behaviour,  together  wdth  a  for- 
nial  analysis  of  this  behaviour  is  thus  the  main  contribution  of  our  work.  Different  approaches  for  specification 
of  real-time  and  reactive  systems  range  over  automata-based,  temporal  logics,  Petri  nets,  action  systems  and 
process  algebras.  In  our  view  a  rule-based  language  with  a  formal  semantics  shares  the  benefits  of  these  spec¬ 
ification  languagp.  In  addition,  it  has  a  special  appeal:  it  mimics  the  natural  mode  of  reasoning  by  humans 
m  many  applicpiop.  Therefore,  it  can  be  considered  as  a  powerful  tool  for  capturing  expert  knowledge  and 
formally  analyzing  it.  Moreover,  rules  can  be  executed  and  can  therefore  be  seen  as  both  a  specification  and  a 
programming  language. 

The  synchronous  family  of  high-level  programming  languages  [5]  for  real-time  systems  (Lustre,  Esterel, 
Signal)  share  the  above  characteristic.  They  too  can  be  used  both  for  capturing  high  level  design  and  as 
executable  code.  Thoup  very  different  in  syntax  and  style  of  programming,  adding  reactiveness  to  our  rules 

leads  to  formal  semantics  which  is  reminiscent  of  a  couple  of  the  proposed  semantics  for  Statecharts  [14],  and 
Esterel  [13].  '■  ^ 


2  Rules  and  Reactiveness 


A  reactive  rule-based  system  (illustrated  in  Figure  1)  is  a  system  that  reacts  to  the  changes  of  its  environment 
contmuously  [12].  Such  a  sptem  is  composed  of  three  entities  called  state,  rules,  and  inference  engine.  The  state 
consists  of  slots:  state  variables,  with  associated  pairs  of  values  indicating  the  previous  and  the  current  value 
of  the  slot,  respectively.  During  a  period  when  no  changes  happen  {equilibrium  period,  EP),  the  two  values  of  a 
slot  are  identical.  At  a  point  when  there  is  a  change  (a  stimulus  comes  from  the  environment),  the  current  value 
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of  some  slot  becomes  updated.  We  call  such  a  moment  an  asynchronous  computational  point  (AGP).  At  each 
AGP,  the  stimulus  triggers  one  or  more  rules,  producing  new  changes  in  the  slots,  which  in  turn  trigger  other 
rules,  and  so  on.  This  is  continued  until  no  changes  are  possible,  i.e.  a  steady  state  is  reached.  Then  the  system 
starts  ’’resting”  in  its  new  EP,  awaiting  new  stimuli.  The  inference  engine  is  in  charge  of  the  computations  at 
the  AGPs. 


Fig.  1.  A  reactive  rule-based  system. 


The  rule  language  RL  (syntax  can  be  found  in  the  appendix)  is  developed  to  express  responses  of  the  system 
at  each  AGP.  The  language  has  been  successfully  used  for  developing  a  reactive  application:  a  driver-support 
system  [10]. 

The  rules  in  an  RL  program  have  an  event-condition-action  form,  e.g.; 

WHEN  A  *=  a  IF  (B  *=  b  AND  NOT  E  |=  e)  THEN  D  :=  d; 

read  as  “When  A  changes  to  a  then  if  B  changes  simultaneously  to  b  and  E  has  not  been  e  then  D  obtains  value 
d”.  The  WHEN  part:  A  *=  a  is  called  the  trigger  part  of  the  rule,  the  IF  part:  (B  b  AND  NOT  E  |=  e)  is 
called  the  condition  part  of  the  rule,  and  the  THEN  part  D  :  =  d  is  called  the  assignment  part  of  the  rule.  The 
trigger  part  and  the  condition  part  together  are  called  the  precondition  of  the  rule.  The  characteristics  of  this 
language  are: 

-  The  meaning  of  a  reactive  program  js  independent  of  the  ordering  of  the  rules  (in  case  of  larger  systems  rule 
ordering  is  a  cumbersome  and  error-prone  process;  the  semantics  of  such  programs  is  unclear  and  easy  to 
distort) .  In  our  approach  a  program  can  be  enhanced  by  simply  adding  new  rules  to  the  existing  rule  base; 

-  The  language  assumes  finite  domains  for  variables  (c.f.  datalog)  allowing  a  finite  model; 

-  The  language  allows  the  logical  operations,  negation  and  conjunction; 

-  The  language  allows  for  taking  account  of  concurrent  events  (in  the  example  rule  events  A  *=  a  and  B  *= 
b  occur  simultaneously); 

-  The  language  models  time  flow  without  introducing  metric  time  (E  |=  e  checks  if  “E  has  had  value  e 
before”,  while  E  *=  e  checks  if  “E  has  changed  to  value  e”); 

A  rule  responds  to  external  stimuli  at  a  given  state  by  checking  whether  the  rule  is  enabled  at  the  current 
state,  and  firing  the  rule  (performing  the  assignments)  if  so  is  the  case. 

A  stimulus  to  a  system,  denoted  as  I,  is  a  set  of  changes  which  are  (slot,  value)  pairs.  A  state  of  a  rule-based 
system  is  a  pair  (5,  C)  where  S  contains  the  values  of  all  the  variables  (slots),  and  C  contains  the  set  of  changes. 
We  use  Sa;  to  denote  the  value  of  x  in  the  latest  EP.  During  an  EP,  S  is  the  same  and  G  =  0.  At  an  AGP,  S 
is  the  same  as  S  in  the  previous  EP  and  C  contains  the  changes  occurring  at  this  AGP  including  the  external 
stimuli  and  the  changes  derived  as  the  result  of  the  assignments  of  the  enabled  rules. 

A  rule  r  being  enabled  at  a  state  (5,  C)  is  denoted  by  (5,  C)  h  r.  A  rule  r  being  not  enabled  at  a  state  (5,  C) 
is  denoted  by  {S,C)  \/  r.  To  check  whether  {S,C)  h  r,  we  only  need  to  check  if  all  the  primitive  preconditions 
of  rule  r  are  satisfied  at  {S,C).  By  primitive  precondition,  we  mean  positive  condition  including  X  \=v  (was), 
X  *=v  (changes  to),  or  negative  condition  including  NOT  Z  |=  v  (was  not),  NOT  X  *=  v  (does  not  change 
to).  The  trigger  part  of  a  rule  contains  only  one  primitive  condition  X  *=v  ,  while  the  condition  part  of  a  rule 
can  be  a  conjunction  of  primitive  conditions.  We  define  h  for  rules  by  first  defining  h  for  primitive  conditions 
of  rules,  here  delimited  by  [  ]. 


172 


Perspectives  of  System  Informatics’99 


-  (S',  C)  h  [a;  I  =t;]  iff  5a;  =  v; 

-  iS,C)  h  [a:*=i;]  iff  5a:  i;  and  {x,v)  eC; 

~  negation  (NOT)  and  conjunction  (AND)  are  interpreted  as  standard  logical  connectives.  That  is: 

•  (5,  C)  I-  [  NOT  p]  where  p  is  any  positive  primitive  iff  not  (5,  C)  h  p. 

•  {S,  C)  h  [pi  AND  P2]  where  pi  and  p2  are  primitive  preconditions  iflf  (5,  C)  h  pi  and  (5,  (7)  h  oo 

-  (5,(7)  b' riff  not  (5,(7)  hr.  y  ^ 

Let’s  look  at  a  simple  example.  Suppose  x,  y,  and  z  are  the  three  slots  of  the  system.  Let  =  0,  Sy  ~  0, 
5*  =  0  and  C*  =  /  =  {(x,  1)}.  Program  PI  contains  only  one  rule  rl: 

rl:  WHEN  x  *=  1  IF  y  |=  0  THEN  z  :=  1; 

Rule  rl  is  enabled  at  (5,(7)  since  {x,  1)  E  C  and  Sy  =  0.  The  effect  of  firing  this  rule  is  to  assign  1  to  z. 
Therefore,  the  set  of  changes  becomes  (71  =  {(x,  1),  {z,  1)}. 

Let’s  consider  another  program  P2  containing  only  r2  with  the  same  (5,  (7); 

r2:  WHEN  z  *=  1  IF  y  |=  0  THEN  y  :=  1; 

Rule  r2  is  not  enabled  at  (5,  (7)  since  {z,  V)  ^  C.  Therefore,  the  set  of  changes  is  still  {{x,  1)}. 

If  an  RL  program  contains  several  rules,  then  the  response  of  the  system  at  each  ACP  may  no  longer  be 
only  one  (or  zero)  firing  of  rule.  There  could  be  several  rule  firings  some  of  which  are  caused  by  others. 


3  Synchrony  Assumption  and  Causality 

One  might  ask  why  the  responses  only  occur  at  ACPs.  The  fundamental  assumption  taken  here  is  the  synchrony 
^sumption:  each  response  is  assumed  to  be  synchronous  with  the  effects  it  causes.  This  assumption  is  realistic 
ii  the  responses  of  the  system  are  fast  enough  so  that  the  environment  does  not  change  during  the  responses 
(which  should  be  checked  in  practice).  The  effects  of  the  execution  of  one  component  are  instantly  broadcast  to 
all  the  other  components  of  the  system.  Therefore,  all  the  components  of  the  system  have  the  same  view  of  the 
system  state. 

The  smallest  component  of  an  RL  program  is  one  single  rule.  If  several  rules  get  fired  at  the  same  ACP 
then  all  the  rule  firings  are  considered  to  occur  at  the  same  time.  We  don’t  care  how  the  rule  firings  axe  done 
step  by  step  if  only  synchrony  requirement  is  considered.  What  is  interesting  is  only  the  result  of  the  response. 
The  result  of  a  response  at  (5, 1)  is  a  stable  state  (5,  C)  and  a  set  of  fired  rules  where: 

-  C'  is  the  result  of  firing  all  the  rules  in  Rf  at  the  given  initial  state  (5, 1).  Let  A  denote  the  assignments 
of  rule  r.  Then 

C'=  [J  ArUl. 

reRf 

(5,  C)  is  seen  as  the  state  after  the  response.  . 

“  are  enabled  at  state  (5,C").  First,  all  the  rules  in  Rf  are  enabled  at 

(A,  G  ).  becond,  no  other  rules  not  belonging  to  Rf  are  enabled  at  (5,  C). 

^  However,  we  would  like  to  retain  causality  which  is  a  very  important  property  for  a  reasoning  system.  The 
principle  of  causality  requires  that  any  change  issued  should  have  a  sequence  of  (enabled)  rule  firings  leading 
to  it.  The  following  example  shows  a  causal  reasoning.  By  composing  earlier  programs  PI  and  P2,  we  get  a  new 
program  P3  which  contains  two  rules:  rl  and  r2.  One  can  infer  that  both  rl  and  r2  are  fired  and  the  new 
set  of  changes  becomes  CZ  =  {(x,  1),  {y,  1),  {z,  1)}.  The  reasoning  is  simple.  Since  rl  is  enabled  at  (5,7),  rl 
^  fired  and  the  effect:  the  change  {z,  1)  is  instantaneously  broadcast.  The  system  state  becomes  (5,(71)  where 
Cl  -  {(X  1),  (z,  1)}.  Since  r2  is  enabled  at  (5,  (7l),  r2  is  also  fired  and  results  in  the  final  set  of  changes  (73. 

example,  C  -  (73  and  Rf  =  {rl,r2}.  The  synchrony  requirement  is  also  satisfied  since 
-  J  UAriUAr2,  and  rl  and  r2  are  the  only  rules  enabled  at  (5,  C3). 

However,  not  all  the  responses  respect  both  synchrony  hypothesis  and  the  principle  of  causality.  Let’s  look 
at  two  examples. 

Given  5  where  5a;  =  0, 5^,  =  0, 5^  =  0,  7  =  {{y,  1)}  and  a  program  with  two  rules  r3  and  r4,  what  are  the 
final  state  and  the  fired  rule  set? 

r3:  WHEN  x  *=  1  IF  y  |=  0  THEN  z  :=  1; 
r4:  WHEN  z  *=  1  IF  y  |=  0  THEN  x  :=  1; 
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There  are  two  solutions  which  satisfy  the  synchrony  requirement.  One  is  C"  =  /  and  =  0.  The  other  is 
C'  =  {{y,  I),  {x,  l),{z,  1)}  and  =  {r3,r4}.  The  problem  with  the  second  solution  is  that  without  the  firing 
of  r4,  r3  can  not  get  fired.  The  same  is  for  r4:  without  the  firing  of  r3,  r4  can  not  get  fired.  The  result  is 
self-triggered.  Or,  in  other  words,  it  is  not  causal  since  we  can  not  generate  this  final  result  via  a  causal  sequence 
of  rule  firings. 

The  above  example  shows  that  not  all  the  responses  satisfying  synchrony  requirement  are  causal.  Next,  we 
show  that  not  all  the  causal  responses  satisfy  the  synchrony  requirement  either. 

Suppose  {S,  I)  be  Sx  =  0, 5^  =  0, 5^  =  0,  /  =  {(y,  1)},  and  a  program  be  as  follows. 

rS:  WHEN  y  *=  1  IF  MOT  x  *=  1  THEN  z  :=  1; 
r6:  WHEN  y  *=  1  IF  x  1=0  THEN  x  :=  1; 

A  causal  rule  firing  sequence  is  r5  followed  by  r6  which  results  in  ' 

C"  =  {(y,  1),  (a;,  1),  (z,  1)}.  The  problem  is  that  r5  is  not  enabled  at  {S,C')  which  violates  the  fynchrony 
requirement. 


4  Other  Requirements  , 

As  we  deal  with  variables,  one  important  requirement  is  not  to  assign  different  values  to  the  same  variable  at 
the  same  AGP.  Another  requirement  is  that  there  should  be  only  one  final  result  at  each  AGP.  This  requirement 
is  understood  as  observable  determinism. 

Next,  we  provide  a  desired  semantics  definition  for  a  response  which  respects  the  synchrony  hypothesis,  the 
principle  of  causality  and  the  above  requirements. 


5  Declarative  Semantics 

Definition  1.  Suppose  R  is  the  set  of  rules  of  a  program  P.  The  declarative  response  of  the  program  P  in  a 
state  {S,I)  is  any  sequence  of  firings 


(ToCTi  . . . 


such  that 

-ao  =  (C'o,i2oO=(/,0), 
~  0>'i+l  =  (Ci+l  1 -^^l) 


{Ci  U  Arf , Ri  U  {r/})  where  rf  G  R-{r\r  e  R\R{  A  (S', Ci)  h  r} 


ifR  =  > 


ifR^dl 


□ 

In  the  definition,  each  firing  (o-j)  contains  a  set  of  changes  (Ci)  and  a  set  of  fired  rules  {R{). 

It  can  be  proved  that  a  declarative  response  has  always  a  finite  length  [8]. 

Definition  2.  Let  R  be  the  rule  set  in  a  program  P.  Let  a  declarative  response  of  the  program  in  a  state  {S,  0)  to 
a  stimulus  I  be  a^ai .  ..am-  Let  am  —  {Cm,R^)  and  R^  =  {ri,r2, . .  .,rm}-  The  declarative  response  is  correct 
if  and  only  if 


-  the  response  is  rule-consistent; 

\/r{reRf-^iS,Cm)^r). 

that  is,  none  of  the  rules  fired  in  this  response  will  become  disabled  after  the  final  firing; 

-  the  response  is  slot-consistent; 

'^x{{x,Vi)  e  Cm  A  {x,V2)  e  Cm  Vi  -  V2) 

that  is,  no  slot  can  have  more  than  one  change  of  value  in  this  response; 

-  the  response  is  unambiguous;  for  any  other  declarative  response  aoa[  ...ct^  with  a'^  —  {C'^,R'^)  that  is 

both  rule- consistent  and  slot- consistent,  we  have  C'j^  —  Cm-  □ 
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A  correct  response  is  the  desired  response.  This  semantics  is  referred  to  as  declarative  semantics.  An  RL 
program  is  correct  if  and  only  if  it  has  a  correct  response  for  any  possible  combination  of  state  and  stimuli 
Two  natural  questions  arise: 

-  Can  we  construct  an  operational  semantics  to  implement  the  desired  declarative  semantics? 

-  Can  we  identify  the  ill-behaved  programs  during  compile  time  without  having  to  generate  all  the  responses 
for  each  state-and-stimulus  combination? 

We  will  devote  the  next  two  sections  to  answering  the  above  questions. 


6  Constructive  Semantics 

6.1  The  semantics 

Constructive  semantics  is  an  application  of  the  three-valued-logic  approach  to  non-monotonic  reasoning  in  the 
seUmg  of  reactive  systems.  It  also  resembles  the  recently  proposed  semantics  for  pure  Esterel  [131.  The  main 
differences  are  m  the  structure  of  programs  (rule-based  in  our  case,  imperative  in  the  case  of  Esterel),  and  the 
means  of  communication  (change  in  slot  values  in  our  case,  pure  signals/events  in  Esterel).  In  what  follows  we 
present  the  constructive  semantics. 

The  constructwe  semantics  needs  not  only  positive  information  about  the  changes  of  the  system,  but  also 
negative  information  about  the  lack  of  changes.  In  constructive  semantics,  we  deal  with  extended  system  state 
{S,Z)  where  5  records  the  values  of  the  slots  before  the  AGP  and  Z  contains  a  set  of  annotated  changes  where 
each  (slot,  value)  pair  has  a  annotation  indicating  the  status  of  this  change.  The  status  is  an  element  from  the 

positive,  and  {x,  u)+  means  that  {x,  v)  does  occur  in  this  AGP;  -  is  read  as  negative, 
and  (a;,  v)  means  that  the  change  {x,  v)  can  not  possibly  occur  in  this  AGP;  i.  is  read  as  Unknown,  and  (x,  v)-^ 
means  that  the  change  of  a:  to  u  is  not  present  yet  at  this  point  of  the  computation,  but  it  is  not  sure  whether 
It  will  take  place  later. 

The  result  of  evaluation  of  a  rule  is  one  of  the  following:  True,  False  or  Unknown  instead  of  only  TVue  or 
Palse  as  m  2- valued  logic.  The  evaluation  evaluates  a  rule  to  be  Unknown  if  it  is  not  known  whether  the  rule  will 
evaluate  to  true  or  false  after  this  response.  More  specifically,  a  primitive  condition  (NOT  x  *=  v)  is  evaluated 
to  be  7Vue  at  a  state  {S,C)  if  (x,v)  does  not  belong  to  C  when  reasoning  under  2-valued  logic,  but  Unknown 
nega«v5^^  constructive  semantics  if  {x,v)  is  not  explicitly  marked  with  unchangeable  status  (positive  or 

The  ordering  between  the  status  annotations  is 


—  {(-^!  ■  ))  (-J-!  +))  (T,  ±),  (—,—),  (-fj  -j-)}. 

Let  Z,  Z  be  two  sets  of  annotated  changes.  Z  is  less  informative  than  Z',  denoted  Z  :<  Z'  if  and  only  if 

(V(x, u)“  e  Z)i3a'){(x, v)^'  eZ‘ ha  <  a'). 

Given  C,  C'^  is  defined  as  the  extension  of  C  where: 


C'+={(x,u)+  I  {x,v)  €  (7}  U  {{x,v')-  1  {x,v)  £C  hv'  ^v}{J 

^  {{x,v)-^  \'iv'{x,v')  ^C] 

Symmetrically,  given  Z,  Z^  is  defined  as  the  reduction  of  Z  where: 


Z  ={{x,v)\{x,v)"^  e.  Z). 


A  rule  being  3-enabled  at  an  extended  state  (5,  Z)  is  denoted  by  {S,  Z)  hs  r.  A  rule  being  3-non-enabled  at 

f  K  if  ^  preconditions  are 

evduated  to  be^ue  at  (5,  Z).  (5,  Z)  r  if  and  only  if  one  of  the  primitive  precondition  is  evaluated  to  be 
liaise  at  (6,  Z).  The  evaluation  of  a  primitive  condition  p  at  a  given  extended  state  {S,  Z)  is  shown  as  follows: 


-  [a;  I  =u]  is  True  if  Sx  =  u; 

[a:|=uj  is  False  if  Sj,  ^  u; 

-  [x*='F\  is  True  if  {x,  v)+  e  Z  and  7^  v; 
[x*=v]  is  False  if  {x,v)-  £  Z  or  Sx  =  v; 
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-  [NOT  p]  is  True  if  p  is  False;  [NOT  p]  is  False  if  p  is  True; 

-  With  the  exception  of  [True],  all  other  primitive  conditions  are  evaluated  to  Unknown. 

It  should  be  observed  that  there  are  intermediate  cases  when  neither  (5,  Z)  h-3  r  nor  (5,  Z)  I/3  r  is  true. 

The  negative  changes  are  derived  by  function  never.  Function  never  works  iteratively.  At  each  iteration, 
a  negative  change  is  added  into  the  set  of  annotated  changes.  The  change  added  has  one  of  the  following 
characteristics: 

-  No  rule  in  the  program  can  issue  such  change. 

-  All  the  rules  that  can  issue  such  change  are  3-non-enabled  at  the  current  extended  state. 

When  we  say  adding  negative  changes  or  positive  changes,  we  mean  updating  the  annotation  of  the  (slot, 
value)  pair  in  the  set  of  annotated  changes.  This  is  done  by  update  function.  The  annotation  can  only  be 
changed  from  ±  to  +  or  -.  An  attempt  to  change  the  status  from  +  to  -  or  vice  versa  indicates  a  symptom 
of  slot-inconsistency.  When  such  situation  occurs,  the  set  of  annotated  changes  returned  is  an  empty  set  to 
indicate  failure.  The  formal  definition  for  never  and  update  can  be  found  in  [8]. 

We  are  now  in  a  position  to  define  an  operational  semantics. 

Definition  3.  Given  a  program  P  with  a  rule  set  R,  an  initial  system  sthte  (5, 0),  and  a  stimulus  I,  the 
constructive  response  of  the  program  is  a  sequence 

.  To7i  •  •  • 

such  that 

-  7o  =  (.^0,0) j  where  Zq  =  never(5,/+,i?), 

“  7i+l  ~  ^i+l) 

ifZi  =  9, 

(never(S',update(Zi,  U  {r/})  if  Zi^0  and 

Vf^Ri 

iZi,R{)  ifRi  =  <ll, 

where  Ri  =  {r|r  €  R\R{  A  (5,  Zi)  hs  r}.  O 

As  we  can  see,  if  there  exists  an  unfired  rule  3-enabled  in  the  current  state,  and  no  slot-inconsistency  occurred 
in  the  update  of  the  previous  step  {Zi  ^  0),  then  the  current  set  of  annotated  changes  Zi  is  updated  with  positive 
changes,  and  negative  changes.  The  positive  changes  come  either  from  the  external  stimulus  (step  0)  or  from 
the  assignments  of  the  selected  rule  that  is  3-enabled  at  the  current  extended  state  (subsequent  steps).  The 
negative  changes  derived  by  never  function  are  those  potential  negative  changes  that  could  be  deduced  from 
the  current  state.  If  there  is  no  unfired  rule  3-enabled  by  the  current  state,  then  the  procedure  returns  the  same 
tuple  as  in  the  previous  step.  Finally,  if  the  state  indicates  the  occurrence  of  slot-inconsistency  {Zi  =  0),  the 
procedure  returns  the  empty  set  as  the  new  set  of  annotated  changes.  _ 

We  say  that  the  constructive  response  terminates  at  Zm  if  and  only  if  {Zm-  =  0  and  Zm-i  Zm)ox  {Rm  =  0 
and  Rm-i  #  0),  that  is,  a  slot-inconsistency  occurs  or  there  is  no  rule  to  be  selected. 

A  terminating  constructive  response  is  accepted  if  and  only  if  it  terminates  at  Zm  and  Zm  0  and 
(V(x,  v)“  e  Zm){a  ^  J-).  That  is,  an  accepted  constructive  response  terminates  normally,  meaning  that  no 
slot-inconsistency  occurs  {Zm  7^  0),  and  the  set  of  annotated  changes  of  its  final  state  is  complete,  meaning  that 
no  change  in  Zm  is  marked  with  _L. 


6.2  Properties 

It  can  be  proved  that  given  a  program  P  and  {S,I),  all  the  constructive  responses  reach  the  same  final  set  of 
annotated  changes  (the  thereom  can  be  found  in  [8]). 

It  can  also  be  proved  that  any  accepted  constructive  response  yields  a  correct  declarative  response.  In  order 
to  prove  this,  we  first  define  a  mapping  from  an  accepted  constructive  response  to  a  sequence  of  firings  and 
then  prove  that  this  sequence  is  a  construction  of  a  declarative  response  (see  [8]).  Then,  we  prove  that  this 
declarative  response  is  a  correct  one  (see  theorem  1). 
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^  ~  7o7i  ■•■7m  be  an  accepted  constructive  response,  where  7i  =  {Zi,R{),Q  <  i  <  m. 

map(C'i2)=CTo,<Ti,...,cr^, 

where  ai  =  {Z-,R().  ^ 

I'iZTcR,  ««  accepted  cenetruetice 

□ 

The  proof  can  be  found  in  [8]. 

The  static  checker  performs  an  exhaustive  check  of  acceptability  of  the  responses  for  all  possible  states  and 
stimuli  It  can  be  easily  proved  that  that  all  the  programs  passing  the  constructive  check  procedure  ^e  correct 
ones  with  respect  to  the  desired  declarative  semantics. 


7  Stratified  Program 

7“°"  ■“  loP'  programming  and  deductive  databases.  It  was  an  early 

MraS  cTals  *’'7'*"  “  prp»e«»  of  negation.  The  flxpolnt  computation  along 

bastt  f  If  ,  f  We  introduce  the  idea  of  stratification  into  reactive  mlf 

a  iStion  mOTl^  r?  T'  rale-mnsistent 

nee  a  condition  (NOT  a;  *=  v)  of  a  rule  r  can  be  disabled  by  firing  other  rules  after  r,  which  may  generate 

hilhe  1  Working  with  stratified  fule  sel 

as  the  folloTOng  effect:  every  time  a  rule  which  has  a  condition  part  including  negation  over  rs*=u]  is  tested 

or  being  enabled,  we  c^  be  sure  that  a  rule  with  an  assignment  v  to  s  has  been  fired  earlier  in  the  response 
(if  It  IS  included  in  the  final  fired  rule  set  of  this  response  at  all).  response 

^iinnn  ?’  not  explicitly  consider  these  dependencies  when  introducing  rules  The 

support  at  compile  time  is  supposed  to  check  whether  such  a  stratification  exists.  Given  a  progrfm  P  and  a 
pair  (a:  n)  the  definition  of  {x,v)  is  the  set  of  rules  in  whose  assignment  part  {x,v)  appears 

A  stratified  rule-based  program  consists  of  a  disjoint  set  of  rules  P  =  P^  U  . . .  U  P*  U  U  P'^  called  strain 
If  a  program  is  stratifiable,  its  stratification  is  constructed  as  follows:  ’ ' 

■  u  coSm  srj,i 

”  <iPfl«W0P  is  contained 

if  to  ie^M  comIfilifTiT'f  ’’■■“f™’  ‘'i®  rosppuses  generated  by  such  operationaj  semantics  are  correct 
1  they  are  slot-consistent.  Unfortunately,  for  a  stratibed  program  this  operational  semantics  does  not  guarantee 
slobconsistency.  Stratification  simply  provides  a  sufficient  condition  for  rule-consistency. 

8  Summary 

The  technical  results  obtained  in  our  research  can  be  summarized  as  follows: 

""  defined  a  rule-based  language  RL  that  combines  asynchronous  interaction  with  an  environment 

-  treatment  of  a  response.  Time  and  concurrency  are  thus  dealt  with  in  a  simple  manner- 

atomicity  an^^liimd  dXtlTml 

-  We  have  defined  a  correctness  criterion  for  reactive  RL  programs.  A  correct  program  ensures  termination  of 

S  &m;  “  "“I™  «->'  nl  rSt  Zf 

~  and  implemented  constructive  semantics,  based  on  three-valued  evaluation  of  rules  that 

guarantees  the  correct  results  of  computations  for  correct  programs-  ’ 

:  wl  r  "net? ““  ~- 

■  !Z  -PPOrt  -Wch  guatautees  correctuesa  w.t.t. 
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A  Appendix:  Syntax 

The  syntax  for  RL  is  defined  as  follows. 

Definition  5.  A  rule  is  a  string 

WHEN  <rtrig>  IF  <rcond>  then  <rassign> 

fulfilling  the  requirements  of  the  following  grammar: 

<Ttrig>  <slot-name>  *=  <slotval> 

<slotvat>  <ident> 

^rcond^  cond^  AND  ^rutgral^ 

I  ^fliteral^ 

I  TRUE 

literal^  '^Oiteroi^ 

I  <slot-name>  *=  <slotval> 

I  <slot-name>  1=  <slotvat> 

<Tassign>  <assignment>  I  i  <assignment-list>  } 

<assignment-list>  ::=  <assignment>  1  <assignment-list>  ,  <assignment> 
<assignment>  <slot-name>  :=  <slotval> 

<slot-name>  <ident> 

where  <ident>  denotes  an  identifier. 
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Abstract.  We  present  a  proof  system  for  verifying  CCS  processes  in  the  modal  /r-calculus.  Its  novelty  lies 
m  the  generality  of  the  proof  judgements  allowing  parametric  and  compositional  reasoning  in  this  complex 
setting.  This  is  achieved,  in  part,  by  the  use  of  explicit  fixed  point  ordinal  approximations,  and  in  part 
y  a  complete  separation,  following  an  approach  by  Simpson,  of  rules  concerning  the  logic  from  the  rules 
encoding  the  operational  semantics  of  the  process  language. 


1  Introduction 


In  a  number  of  re^nt  papers  [1-4,9]  proof-theoretical  frameworks  for  compositional  verification  have  been  put 
forward  based  on  Gentzen-style  sequents  of  the  shape  Fh  A,  where  the  components  of  F  and  A  are  correctness 
assertions  P  :  Several  programming  or  modelling  languages  have  been  considered,  including  CCS  [3]  the 
TT-caiculus  [2],  CHOCS  [1],  general  GSOS-definable  languages  [9],  and  even  a  significant  core  fragment  of  a 
real  programming  language.  Erlang  [4].  An  important  precursor  to  the  above  papers  is  [10]  which  used  ternarv 
sequents  to  build  compositional  proof  systems  for  CCS  and  SCCS  vs.  Hennessy-Milner  logic  [6]. 

A  key  idea  is  that  the  use  of  a  general  sequent  format  allows  correctness  properties  P  ;  0  to  be  stated  and 
proved  in  a  parametric  fashion.  That  is,  correctness  statements  ^  of  a  composite  program  P(Qi,Q2),  say  can 
be  relativized  to  correctness  statements  of  the  components,  QuQ^.  A  general  rule  of  subterm  cut 


F  \-  Q  :'ip,A  F,x  :  ip  P  :  ^,A 
F  1-  P{Q/x]  :  (t>,  A 


(i) 


allows  such  subterm  assumptions  to  be  introduced  and  used  for  compositional  verification. 

support  temporal  properties  within  such  a  framework.  As  is  well  known  [12],  logics 
UKe  biL,  CIL,  or  CTL  are  poorly  equipped  for  compositional  reasoning  without  resort  to  devices  like  history 
or  prophecy  variables.  For  this  reason,  our  investigations  have  tended  to  focus  on  logics  based,  in  some  form  on 
the  modal  ^i-c^culus  in  which  the  recursive  properties  needed  for  property  decomposition  can  more  adequately 
e  expressed.  In  [3]  the  first  author  showed  one  way  of  realizing  a  proof  system  using  the  subterm  cut  rule, 
and  bmlt,  for  the  first  time,  a  compositional  proof  system  capable  of  handling  general  CCS  terms,  including 
to  addrefs  Processes  dynamically.  In  [4]  we  used  a  similar,  though  considerably  improved,  approach 

The  approach  of  [3]  suffered  from  two  main  shortcomings,  however: 

1.  Though  systeinatic,  the  embedding  of  the  CCS  operational  semantics  into  the  proof  system  was  indirect 
and  allowed  only  rather  weak  completeness  results  to  be  obtained. 

2.  The  handling  of  recursive  formulas  was  very  syntactic  and  hedged  by  complicated  side  conditions,  hiding 
txie  essence  oi  our  proof-theoretical  approach  from  view. 

?  P^P®^  are  addressed.  First,  following  an  idea  by  Simpson  [9]  we  fully  separate  the 

mbedding  of  the  transitional  semantics  for  P  from  the  general  handling  of  the  logic  by  employing  process 
variables  and  transition  assertions  of  the  shape  P  4  g.  These  assertions  provide  a  semantically  explicit  bridge 
between  the  transitions  of  P  and  the  one-step  modalities  of  the  logic.  A  similar  approach  is  used  to  handl 
the  second  complication.  The  essential  difficulty  is  that,  to  be  sound,  rates  of  progress  for  fixed  point  formulas 
appearing  in  different  places  in  a  sequent  must  be  related.  To  achieve  this  in  a  simple  and  semantically  explicit 
way  we  employ  fixed  point  approximations  using  ordinal  variables,  and  ordinal  constraints  of  the  shape 

"  ®  paper  we  first  introduce  the  modal  /i-calculus  with  explicit  ordinal  approximations,  and  we  introduce 

the  basic  form  of  judgment  used  in  the  proof  system.  In  the  absence  of  process  structure  such  as  CCS,  models 
are  just  standard  Kripke  models.  Correspondingly,  the  proof  system  in  this  case  can  be  seen  to  provide  an 
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account  of  Gentzen-style  logical  entailment.  The  novelty,  in  this  case,  lies  in  the  use  of  ordinal  approximations. 
This  fragment  of  the  proof  system  is  introduced  in  Sect.  3.  The  key  ingredient  to  release  the  power  of  this  proof 
system  is  a  rule  of  discharge,  or  termination,  which  recognizes  proofs  by  well-founded  induction.  In  another 
paper  [5]  we  introduce  a  game  which  embodies  such  a  rule,  and  show  completeness  of  the  resulting  proof  system 
by  reduction  to  Kozen’s  well-known  axiomatization  [7].  A  practical  rule  of  discharge,  however,  must  be  local 
which  the  game  condition  of  [5]  is  not.  Here,  instead,  we  introduce  a  local  version  of  the  discharge  rule  which 
is,  we  believe,  a  simple  and  intuitive  approximation  of  the  complete  global  condition.  This  local  discharge  rule 
is  introduced  (summarily,  in  this  abstract)  in  Section  4.  A  full  instantiation  of  our  approach  to  CCS  requires 
in  addition  an  embedding  of  the  CCS  operational  semantics  into  th4  present  Gentzen-style  format  (following 
Simpson  [9])  plus  the  subterm  cut  rule  (1).  This  extension  is  shown  in  Section  5,  and  then  in  Section  6  we  give 
a  rough  sketch  of  a  correctness  proof  of  a  simple  infinite  state  CCS  process. 

2  Logic 

Formulas  (p  are  generated  by  the  following  grammar,  where  k  ranges  over  a  set  of  ordinal  variables,  a  over  a  set 
of  actions,  and  X  over  a  set  of  propositional  variables.  , 

\ 

<!)■.■.=  (pW<f>  I  -«p  I  {a)(f>  I  X  I  fiX.<p  I  inX.cP)'^ 

An  occurrence  of  a  subformula  in  is  positive,  if  appears  in  the  scope  of  dn  even  number  of  negation 
symbols.  Otherwise  the  occurrence  is  negative.  The  formation  of  least  fixed  point  formulas  of  one  of  the  shapes 
nX.<j>  or  {nX.<l)Y  is  subject  to  the  usual  formal  monotonicity  condition  that  occurrences  of  X  in  0  are  positive. 
We  use  the  symbols  U  and  V  to  range  over  (unindexed)  fixed  point  formulas  fjiX.(j>.  A  formula  (j>  is  propositionally 
closed  if  (p  does  not  have  free  ocurrences  of  propositional  variables.  Standard  abbreviations  apply: 

false  =  fiX.X, 
true  =  -tfalse, 

<p  Alp  =  V  ~‘'ip), 

[a]<p  = 

vX.<p  =  --pX.-^{(PYX/X]) 

We  assume  the  standard  modal  /it-calculus  semantics  [7]:  - 

UyipWp^  ll^illpullV'lb 

||-i^|1p  =  5\|l^!|p 

\\{a)4>\\p^{P\^Qemp.P^Q] 

\\X\\p  =  p{X) 

||MX.^||p=f|{5|5C|i,^||p[5/X]} 

augmented  by  the  clause: 

r  0  if  p{k)  =  0 

wipx.cprwp^l  \\m\\ipx.mp/x,p/>A  ifp(K)  =  ^+i 

I  [J{\\iP^-^)^\\p[^/'^]  I  ^  if  is  ^  limit  ordinal 

where  p  is  an  interpretation  function  (environment),  mapping  ordinal  variables  to  ordinals,  and  propositional 
variables  to  sets  of  closed  process  terms,  or  states,  from  a  domain  S  ranged  over  by  P. 

The  use  of  ordinal  approximation  hinges  on  the  following  results  (of  which  (1)  is  the  well-known  Knaster- 
Tarski  fixed  point  theorem). 

Theorem  1. 

1.  \\px.cp\\p  =  ]jp\\(px.cpr\\p[p/K] 

2.  \\{px.<pr\\p  =  Up^^^,,)\\m\\ip^-mp/x,^/K] 
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Observe  how  this  casts  the  properties  U  and  C/'"  as  existential  properties:  This  is  useful  to  motivate  the 
proof  rules  for  fixed  point  formulas  given  below.  Observe  also  that,  for  countable  models,  quantification  over 
countable  ordinals  in  Theorem  1  suffices.  In  the  definition  below,  we  extend  interpretation  functions  p  to  map 
process  variables  x  to  closed  process  terms  (states). 

Definition!  (Assertions,  Judgements). 

1.  An  assertion  is  an  expression  of  one  of  the  forms  E:<t>,  k<k',  orE^F,  where  E,F  are  a  process  terms 
and  (f)  is  a  propositionally  closed  formula. 

2.  The  assertion  E  :  ^  is  valid  for  an  interpretation  function  p  (written  E\^p4>),  if  Ep  e  ||0||/3.  The  assertion 
K  <  k'  is  valid  for  p,  if  p{k)  <  p{k').  The  assertion  E  F  is  valid  for  p,  if  Ep  Fp  is  a  valid  transition. 

3.  A  sequent  is  an  expression  of  the  form  Fh  A,  where  F  and  A  are  sets  of  assertions. 

4-  The  sequent  F  ^  A  is  valid  (written  F  ^  A),  if  for  all  interpretation  functions  p,  all  assertions  in  F  are 
valid  for  p  only  if  some  assertion  in  A  is  valid  for  p  as  well. 

An  assertion  of  the  shape  E  :  <l>  is  called  a  property  assertion,  an  assertion  of  the  shape  k  <  k’  is  called  an 
ordinal  constraint,  and  an  assertion  of  the  shape  E  F  is  called  a  transition  assertion. 


3  Proof  System:  Logical  Entailment 

We  first  consider  the  problem  of  logical  entailment.  In  this  case,  process  terms  E  in  assertions  of  the  shape  E  :  6 
are  variables. 

Structural  Rules  We  assume  the  axiom  rule,  the  rule  of  cut,  and  weakening: 


r,AhA,A 

^_rv-A,A  r,AY-A 

COT  - 

,  r  h  A  „  r  h  A 

^'^r,AhA  TV' a; A 

As  in  [9],  in  the  axiom  rule  assertion  A  needs  only  be  instantiated  to  transition  assertions,  and  then  A  can  be 
^sumed  to  be  empty.  Since  F  and  A  axe  sets,  structural  rules  like  permutation  and  contraction  are  vacuous. 
We  conjecture  that  both  cut  and  the  weakening  rules  are  admissible. 


Logical  Rules  In  the  following  listing  we  assume  that  U  =  pX.(j). 


F.\-E-.(j>,A 
F,E-.-n(j>\-  A 


F,  E  :  (j>  j-  A 
F  E  :  -^(p,  A 


F,E:cPh  A  ^E-.xfi-A  ^,.^rbE:(j>,E:iP,A 
F,:^:<f>\/xPi- A  F\- E:<p\/ i;,  A 

(a)-L  ^  A  freshix) 

'  '  F,E  ■{a)4>Y-  A 

(al-R  ri:E^E',A  FV-E'-.4>,A 
'  ’  T  h  E-.  {a)  (P,  A 

rr^rhE:cP\UIX],A 

^  ^  F,E:Ui- A  rrE-.U,A 

rr«,T.  r,K'  <k,E-.  <P[U‘^  /X]  I-  A  y  w 

F,E  A  Fesn[K  ) 

rr«  u  I"  ^  FhE:  (p\U'^' /XIA 

F[-E:U'^,A 

ofthe  ruir^^^*^°^  (^•esf^(K))  is  intended  to  mean  that  x  (k)  does  not  appear  freely  in  the  conclusion 

The  rules  for  unindexed  and  indexed  fixed  point  formulas  are  directly  motivated  by  Theorem  1.  The  lack  of 
symmetry  between  rules  U-L  and  U-R  is  not  accidental;  their  symmetric  counterparts  are  in  fact  admissable. 
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Ordinal  Constraints  Finally,  we  need  to  provide  rules  for  reasoning  about  ordinal  constraints. 


OrdTr 


r,  k'  <  K  I-  k"  <  k',  a 
r,  k'  <  k\-  k"  <  k,  a 


This  rule  is  sufficient  provided  ordinal  variables  and  constraints  are  only  being  introduced  during  the  proof,  i.e., 
do  not  appear  in  the  root  sequent. 


Theorem  2  (Local  Soundness).  All  rules  for  logical  entailment  are  individually  sound:  Each  rule’s  conclusion 
is  valid  whenever  its  premises  are  valid. 


4  Proof  System:  Rule  of  Discharge 

Processes  and  formulas  can  be  recursive,  allowing  for  proof  trees  to  grow  unboundedly.  Intuitively,  one  would 
like  to  terminate  an  open  branch  whenever  a  “repeating”  sequent  is  reached,  i.e.  a  sequent  which  is  an  instance, 
up  to  some  substitution  a,  of  one  of  its  ancestors,  its  “companion”,  in  the  proof  tree.  A  proof  structure,  all  leaf 
nodes  of  which  are  either  axioms  or  such  repeating  nodes,  serves  as  the  basis  for  well-founded  ordinal  induction 
arguments.  A  global  discharge  condition  is  a  sufficient  condition  for  such  an  argument  to  be  valid.  In  case  a  global 
discharge  condition  applies  all  leaves  which  are  not  dxioms  can  be  considered  induction  hypothesis  instances  in 
some,  possibly  deeply  nested,  proof  by  well-founded  induction. 

The  use  of  ordinal  variables  and  constraints  allows  global  discharge  conditions  to  be  phrased  in  a  clear  and 
semantically  transparent  way.  The  most  general  view  of  discharge  is  presented  in  game-based  terms  elsewhere 
[5].  In  essence,  global  discharge  guarantees  well-foundedness  of  proofs;  That  along  every  infinite  path  in  the 
infinitely  unfolded  proof  tree,  ordinal  constraints  grow  downwards  in  an  unbounded  manner. 

Here  we  present  a  discharge  condition  which  is,  in  contrast  to  the  global  condition  of  [5],  more  local,  and 
easier  to  understand  and  apply.  Moreover,  even  though  it  is  in  general  incomplete,  it  is,  in  our  experience, 
adequate  in  a  great  many  situations.  In  particular  it  is  powerful  enough  to  handle  the  example  considered 
below. 

First  a  single  piece  of  terminology:  Two  repeat  nodes  are  called  related  if  they  are  in  the  same  strongly 
connected  component  in  the  directed  graph  obtained  from  the  proof  structure  by  identifying  the  repeat  nodes 
with  their  companions. 

Definition  2  (Rule  of  Discharge).  A  node  labelled  F  \-  A  can  be  discharged  with  and  substitution  a 
against  an  ancestor  node  labelled  F'  'r  A'  if: 

(i)  t/''  occurs  as  subformula  in  F'  or  A'  ; 

(ii)  (pa  G  F  whenever  (p  G  F' ,  and  <pa  G  A  whenever  (p  G  A'; 

(Hi)  F  \-  Ka  <  K  is  derivable; 

(iv)  assuming  the  related  discharge  nodes  labelled  Fi  Y-  Ai' ... Fn  An  have' been  discharged  with  •■•Un’' 
and  ai  ..  .an  against  FI  \-  A'l  . .  .FnV-  A'n,  there  is  a  linear  ordering  •<  on  these  discharge  nodes  including 
the  present  node,  such  that  whenever  i  j:  (a)  f/"'  occurs  as  subformula  in  Fj  or  A'j,  and  (b)  either 
Kiaj  =  Ki,  or  Fj  Kiaj  <  /t,  is  derivable. 

In  clause  (iv),  the  linear  ordering  can  be  chosen  differently  each  time  the  rule  is  applied  (and  a  new  node  is  added 
to  the  corresponding  class  of  related  discharge  nodes).  The  purpose  of  the  clause  is  to  guarantee  that  along 
every  infinite  path  in  the  infinitely  unfolded  proof  tree,  ordinal  constraints  grow  downwards  in  an  unbounded 
manner. 

Theorem  3  (Soundness).  The  proof  system  including  the  rules  for  logical  entailment  and  the  rule  of  discharge 
is  sound:  All  sequents  derivable  in  the  proof  system  are  valid. 

The  full  version  of  the  paper  explains  the  discharge  mechanism  in  greater  detail  and  gives  a  soundness  proof. 
For  finite  state  labelled  transition  systems  the  above  proof  system  reduces  to  an  ordinary  model  checker  like 
the  one  presented  in  [11],  and  is  hence  complete  for  such  systems.  In  general,  however,  due  to  undecidability  of 
the  model  checking  problem  addressed  here,  the  system  is  necessarily  incomplete. 
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5  Proof  System:  Operational  Semantics 


Having  transition  assertions  allows  the  transitional  semantics  of  a  process  language  to  be  embedded  directly  into 
the  proof  system  as  a  separate  set  of  proof  rules.  This  can  be  done  in  a  straightforward  manner  for  any  GSOS- 
definable  language  [9].  Here  we  illustrate  this  approach  on  a  well-known  process  language,  Milner’s  Calculus  of 
Communicating  Systems  [8]. 

We  assume  that  CCS  process  terms  E  are  generated  by  the  following  grammar,  where  I  ranges  over  a  given 
set  of  labels,  L  over  subsets  of  this  set  of  labels,  a  over  actions  of  the  shape  r,  I  or  I,  and  x  over  a  set  of  process 
variables. 

E::=0\a.E\E  +  E\E\E\E\L\x\fixx.E 

The  set  of  states  S  used  in  Section  2  is  the  set  of  all  closed  process  terais.  The  operational  semantics  of  CCS  is 
given  as  a  closure  relation  on  processes  through  a  set  of  transition  rules  [8]:  the  transitions  that  a  CCS  process 
can  perform  are  exactly  those  derivable  by  these  rules.  Hence,  the  transition  rules  can  be  included  directly  as 
right  introduction  rules  into  our  proof  system,  while  the  left  introduction  rules  (stating  what  transitions  are  not 
possible),  come  from  the  closure  assumption. 

For  lack  of  space  we  present  only  the  most  significant  of  the  resulting  rules  in  this,  abstract,  and  in  particular 
the  ones  used  in  the  Example  to  follow. 

r,0^xhA  ^  E,A 


a-L-1 


r[E/x]  h  A[E/x] 
r,a.E^x\-  A 


r,a.E  ^x\-  A 


oi^  I3 


+  L  E  4  y  h  A[y/x]  r{z/x],  F  4  ^  h  A\zlx\ 

r,E^F  ^xV  A 

^  r\-E^E',A 

Eh  E  +  F  -^E',A 

r\-F-^F',A 
r\-E\F^E'\F',A 

l-L-1  E-^y\-  A\y\F/x]  r\E\z/x],  f\z\-  A\E\z/x] 

F,  E\F  AxY-A 


R  I  r^E^E',A 
r\-  B\F  ^  E'\F,A 


r[yi\F/x],E  ^yi\- A[yi\F/x] 
l-L-2  ^my2/x],F  A- y^l-  A{E\y2/x] 

r[Zi\z2/x],li  —l2,E^  Zi,F  ^  Z2\-  A\z\\z2lx\ 

r,E\FA^xhA 

r,E[fixx.E/x]^y\-  A  F  B\fixx.E/x] E' ,A 

r,fixx.E  ^yh  A  Fh  fixx.E  ^  E',A 

In  addition  to  these  rules,  a  subterm  cut  rule  is  needed  to  allow  for  parametric  and  compositional  reasoning; 


SubtermCut-R 


F  y  F  ■.ip,A  ,  F,x  :  Ip  E  :  (l).A 
F\- E[F/x]:,p,A 


fresh{x) 
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6  Example 


Consider  a  process 


Counter  =  fixx.  up.  (x  \  down.x) 


which  can  alternatingly  engage  in  up  and  down  actions,  generating  a  new  copy  of  itself  after  each  up  action. 
Clearly,  in  any  point  in  time,  regardless  how  many  counters  have  already  been  spawned,  this  system  can  engage 
in  finite  sequences  of  consecutive  down  actions  only.  This  propery  can  be  formalised  as  the  negation  of  the 
following  formula: 

4>  =  lj,X.->fjY,-i{{up)X  \/ {down)-^Y) 


So,  we  want  to  prove  validity  of  the  sequent 


h  Counter :  0 


We  perform  the  proof  backwards,  from  this  goal  sequent  towards  the  axioms,  guided  by  the  shape  of  the  formulas 
and  process  terms  involved.  After  eliminating  the  negation  and  approximating  (j)  one  obtains ' 

Counter ;  h  (2) 

Continuing  in  the  same  straightforward  manner  we  soon  arrive  at  the  following  two  sequents: 


k!  <  K,  up.  {Counter  \  down.  Counter)  x  :  ip 


k'  <  K,  Counter  \  down.  Counter  :  <p'^  h 

the  first  of  which  is  an  axiom.  The  second  sequent  is  similar  to  sequent  (2),  with  the  important  difference  of  a 
new  down.Counter  component  having  appeared.  This  is  the  point  where  one  would  like  to  perform  an  inductive 
argument  on  the  system  structure,  and  this  can  be  done  using  subterm  cut.  The  most  important  question  is  what 
the  property  of  the  component  being  cut  is  that  yields  the  overall  system  property  being  verified.  A  convenient 
case  is  when  it  is  the  same  property,  i.e.,  when  the  property  being  verified  composes  nicely.  This  is  the  case  in 
our  example,  partly  because  there  is  no  communication  between  the  components.  So,  after  two  applications  of 
subterm  cut  we  obtain  the  following  three  sequents: 

k'  <  K,  Counter :  (p'^.  h 

k'  <  K,  down.  Counter  :(/>''  ha;:  cp'^' 

k'  <  K,x\y  :  (p'^  h  a;  '.  (p'^' ,y  :  (p'^' 

the  first  of  which  can  be  discharged  with  0*^  and  substitution  [k  ;t']  against  (2).  Notice  that  this  node  has  no 
related  discharge  nodes  (so  far),  so  only  clauses  (*)  -  (in)  of  the  Rule  of  Discharge  have  to  be  checked  in  this 
case.  The  second  sequent  is  easily  reduced  to  an  axiom  and  a  discharge  node.  Handling  the  remaining  sequent 
is  only  slightly  more  involved  (it  will  be  considered  in  more  detail  in  the  full  version  of  the  paper). 


7  Conclusion 

We  presented  a  proof  system  for  verifying  CCS  processes  in  the  modal  /i-calculus.  Its  novelty  lies  in  the  generality 
of  the  proof  judgements  allowing  parametric  and  compositional  reasoning,  in  the  complex  setting  of  this  powerful 
logic.  This  is  achieved,  in  part,  by  the  use  of  explicit  fixed  point  ordinal  approximations,  and  in  part  by  a  complete 
separation,  following  Simpson  [9],  in  the  proof  system  of  rules  concerning  the  logic  from  the  rules  encoding  the 
operational  semantics  of  the  process  language  (here  CCS).  This  makes  the  proof  system  easily  adaptable  to  other 
languages  with  a  clean  transitional  semantics.  This  adaptability  needs  to  be  further  examined  in  the  future,  in 
particular  in  the  context  of  languages  and  models  with  shared  memory  parallelism. 
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Abstract.  We  review  the  use  of  categories  with  products  as  a  vehicle  for  the  construction  of  bit-level 
functions  that  correspond  to  combinational  circuits.  Further  we  show  that  results  from  the  category  the¬ 
ory  concerning  list  homomorphisms  can  help  in  our  search  for  a  computational  model  that  captures  the 
desirable  properties  of  digital  Circuits,  namely  locality  of  communications  and  simple,  repetitive  structure 
of  computational  components.  We  demonstrate  applications  of  the  theory  to  some  simple  problems. 

1  Introduction  , 

New  reconfigurable  computing  technology  redefines  the  traditional  hardware  /software  boundary  and  enables 
the  rapid  realization  of  algorithm-specific  hardware  architectures  at  a  low-cost  base,  such  as  Field  Programmable 
Gate  Arrays  (FPG A)  [3]. 

We  want  to  develop  a  rigorous  methodology  for  creating  a  range  of  application-specific  high-level  languages 
that  can  be  efficiently  compiled  into  FPGA  arrays.  Two  crucial  issues  should  be  captured  by  our  approach, 
namely  hardware  independent  software  development,  and  efficient  compilation  of  programs  into  digital  cir¬ 
cuits.  Moreover,  since  applications  that  profit  from  reconfigurable  computing  usually  involve  a  high  degree  of 
parallelism  and/or  concurrency  and,  thus,  additional  design  decisions  regarding  decomposition,  arrangement 
of  communication,  routing,  timing,  etc.,  a  good  level  of  abstraction  (which  must  be  mathematically  based)  is 
needed  so  that  reasoning  and  formal  development  are  possible. 

The  categorical  data  type  [8]  approach  is  an  extension  of  the  abstract  data  type  In  a  way  that  appears  to 
be  particularly  useful  for  parallel  computations  [10,6].  CDT  have  operations,  equations  relating  them,  and  a 
guarantee  that  all  of  the  required  operations  and  equations  are  present.  A  theory  of  CDTs  is  a  theory  of  algebraic 
structures  that  behave  “like”  the  constructed  data  type,  and  homomorphisms  among  them.  The  important 
property  of  homomorphic  operations  is  that  the  pattern  of  computations  follows  the  structure  of  the  argument. 
Thus,  for  homomorphic  functions,  locality  of  communication,  regularity  and  partitioning  of  computation  are 
inherent  properties. 

Many  polymorphic  higher-order  functions  are  homomorphisms  or  almost  homomorphisms.  Consider  function¬ 
als  like  map,  that  applies  some  function  to  all  individual  elements  of  a  data  aggregate  independently,  producing 
a  data  aggregate  with  new  values  of  individual  elementsj  or  reduce,  that  calculates  a  “cumulative  sum”  of  all 
elements  in  a  data  aggregate.  These  functionals  can  be  defined  over  different  data  types,  such  as  cons  lists  [2], 
cone  lists  [7]  homogeneous  binary  trees  [7],  arrays  [1],  etc.  While  data  types  vary  from  application  to  application 
(i.e.,  2D  arrays  are  appropriate  data  types  for  image  processing,  lists  for  text  detection,  trees  for  divide  and 
conquer  algorithms,  etc.),  the  general  patterns  of  computation  on  these  types  are  the  same,  and  satisfy  criteria 
of  regularity  and  locality  of  communication,  which  is  important  for  an  efficient  hardware  realization. 

The  main  idea  is  that  for  any  given  application  a  set  of  appropriate  basic  data  types  is  defined  in  terms  of 
categories  with  products,  and  operations  on  these  types  are  compiled  directly  into  blocks  of  FPGA  logic  cells, 
while  higher-order  functions,  or  operations,  for  application  specific  data  aggregates  defined  within  the  scope  of 
CDT,  are  implemented  as  templates  for  composition  of  basic  primitives.  Having  been  carefully  chosen  so  as  to 
satisfy  constraints  of  FPGA  technology,  these  higher-order  functions  ensure  an  efficient  implementation  of  an 
application  on  FPGAs.  In  other  words,  a  possibility  to  express  an  application  in  terms  of  a  composition  of  the 
set  of  predefined  higher-order  functions  on  specific  data  aggregates  is  a  test-bed  for  an  efficient  implementation 
of  the  application. 

2  Categories  with  Products 

To  describe  and  analyse  combinational  circuits  (i.e.,  circuits  without  latches  and  feedbacks)  we  use  a  cat¬ 
egory  with  products.  Let  B  =  {0,1}.  Consider  the  category  Circ  [8]  with  objects  B'’,  B^,  B^,...  and  ar¬ 
rows  that  represent  all  functions  between  these  sets.  Notice  that  B°  =  {*},  or  unit  object,  B^  =  B,  and 
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®  “  {(®i) 3:2,  Xn)  :  Xi  E  B}  for  n  >  1.  In  a  category,  each  morphism  has  a  designated  domain  and  codomain 
in  objects;  any  object  A  has  an  identity  morphism 

1a  ■  A  -A  A, 

and  for  any  given  raorphisms  f  :  A  -A  B,  g  :  B  C,  there  is  a  designated  composition  of  morphisms  (which 
satisfies  identity  and  associative  laws): 

g  °  f  '■  A  -A-  C. 

The  product  of  and  B“  is  B“+"  with  the  following  projections: 

Pi  ;  B“+"  -4  B”,  p2  :  B™+"  -4  B", 

where  (xi,a:2,  and  (*1,2:2,  (x„j+i, x^+n)-  Two  func¬ 

tions  from  B  to  B  are  constants  true  and  false.  Some  further  interesting  functions  in  this  category  are- 
-  :  B  — ^  B  {negation),  &  :  B^  — 4  B  (logical  and),  OiJ  :  B^  B,  and  XOR  :  -4  B  {excluded  or). 

Factions  -1,-0:  B  — ^  B  check  the  equality  of  the  argument  to  1  and  0  respectively ^ 

-  In  a  category  with  products,  we  can  define  a  parallel  composition  of  two  functions:  given  /  :  Jifi  — >  Yi  and 
9  :  X2  -^  Y2,  a  parallel  composition  is  a  function  f  x  g -.  X^  x  X2 Y^  xY^  Which  maps  (xi, X2)  into  a 
pair  {f{xi),9{x2)).  This  function  obeys  the  laws:  py,  o  (/  x  g)  =  fop^,  and  pr^  if  x  g) --  f  opx^,  where 
p’s  are  projections. 

-  A  diagonal  function  A  which  produces  two  copies  of  its  input  can  also  be  defined  in  a  category  with  products 
[8]:  Ax  :X  — y  X  x  X,  suet  that  x  ^4  (x,  x)  and  pi  o  Ax  =  lx,  and  P2oAx  =  lx- 

-  Function  twist  :  X  x  Y  Y  x  X  interchanges  its  two  inputs  :  {x,y)  e4  {y,x),  and  if  pi,  p^  and  qi,  92 
are  the  projections  of  X  x  F  and  F  x  X  respectedly,  than  the  following  laws  hold:  qi  0  twist  =  p^  and 
52  °  twist  —  pi  . 

We  know  [8]  that  in  category  Circ  we  can  construct  any  logical  function  starting  with  functions  true,  false,  not, 
and,  or,  identity  maps,  and  projections  using  only  composition  and  the  property  of  products.  Moreover,  any 
rach  function  can  be  implemented  using  a  circuit  without  latches,  consisting  of  wires  and  gates.  Indeed,  the  set 
B  is  the  set  of  possible  states  of  each  wire.  The  functions  &,  OR  and  XOR  are  implemented  directly  as  gates, 
^  shown  in  Fig.l.  Identity  map(s)  and  =1  simply  correspond  to  a  (group  of  adjacent)  wire(s),  and  -1  (=0)  to 

mverter.  We  can  do  a  number  of  things  with  wires  and  components  that  correspond  to  constructions  of  new 
functions  in  a  category  Circ: 


AND 


=D- 


copy 


zxz 


Fig.  1.  Implementation  of  functions  in  category  Circ. 


-  Splitting  wires  corresponds  to  the  diagonal  function,  Zip  :  B  — >•  B^. 

-  We  can  twist  two  wires.  This  corresponds  to  the  function  twist :  B^  — yB^. 

~  components  side  by  side.  This  corresponds  to  a  parallel  composition,  /  x  p  :  B”  x  B™ _ y 

-  We  can  put  two  components  in  a  series,  connecting  output  wires  of  one  component  with  the  input  wires  of 
another.  This  corresponds  to  composition  p  o  /  :  B"  — y  B™. 


^  ivuvo)  is  defined  in  category  Circ  as  follows: 
I-  u  j  ’  ^  (0)  1)1  (0)0)  (0,0).  In  other  words,  we  want  to  build  a  circuit 

which  produces  two  values:  y,  =  x&(=x  s)  and  po  =  xk{r=o  s),  or  so-called  l-to-2  decoder  [9].  A  decomposition 
of  function  d  is  straightforward:  first,  copy  both  inputs  x  and  s;  pair  them  by  twisting  ’’middle”  elements,  then 
^  It  is  easy  to  see  that  (=1)  =  (1b)  and  (=0)  (-n). 
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apply  functions  =i  (identity  map  1^)  and  =o  (negation  -i)  to  each  copy  of  s,  and  compute  &  of  each  resulting 
pair: 

^  ^ j3  X y^4  Is  X  1  g  X^l g  X  '  Jg4  y^2 


A  circuit  which  implements  a  decoder  function  is  drawn  in  Fig,  2.  Notice  how  the  circuit  corresponds  exactly 
to  the  decomposition  given  above. 

Suppose  now  we  want  to  design  a  2-to-4  decoder:  2dl :  B®  — >  where  (x,  Si,so)  H-  (ys,  «/2,  yi,yo),  such  that 

j/3  =  x&:(=i  6i)&:(—i  So),  y2  =  si)&(=o  sq)',  yi  =  x&c{-o  si)&:(=i  sq),  yo  =  x&c{—o  si)k{—o  sq). 

A  decomposition  can  use  previously  defined  function  d.  Indeed,  first  with  a  l-to-2  decoder  we  compute  partial 
results  x&(=i  si)  and  xSz.{=o  si).  Then  each  of  the  outputs  is  paired  with  signal  sq  (the  latter  must  be  copied 
before)  and  resulting  pairs  are  used  as  inputs  for  two  identical  l-to-2  decoders  each  computing  the  ”=i  so”  and 
”=o  So”  parts  of  the  formulae.  Thus  2-to-4  function  is  decomposed  into  a  sequence  of  parallel  compositions, 
using  so-called  cascading  principle: 

2  —  to  —  4  •  B^  X  B  iBXfwistxlB  g4  g4 

A  corresponding  circuit  is  depicted  in  Fig.  3.  However,  it  is  much  more  tedious  to  describe  and  decompose 


Pig.  3.  2-to-4  decoder. 


into  basic  components,  say  a  4-to-16  decoder,  and  it  is  impassible  to  describe  a  general  n  -  to  -  2",n  =  1,2, ... 
decoder.  In  order  to  be  able  to  manipulate  with  tuples  of  bits  of  any  length,  we  use  concatenation  lists. 


3  Concatenation  Lists 


Suppose  a,  /3,...  are  primitive  data  types,  with  identity  functions  id^  :  a  a,  id^  :  0  defined  for  every 

type.  E  0!  is  a  type,  we  can  form  the  type  a*;  its  elements  are  lists  of  elements  of  type  a.  Cone,  or  join  lists 
[6, 7]  have  three  constructors,  one  that  makes  an  empty  list,  0  :  unit  -4  a*,  another  creates  a  singleton  list, 
[.]  :  a  a*,  and  the  third  concatenates  two  lists  to  make  a  longer  one,  -H-  :  a  *  xa*  a*.  A  table  below 
summarise  some  of  the  list  operations. 
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Combinator  Functions 

distribute-left 

shift-left 

zip 

distl  y  [xu...,Xn]  =  [{yyXi),„.,{y,Xn)] 

T  G  \Xx ,  ...j  Xri\  —  [fi,  X\  5  l] 

zip  [xi , iCn][2/l  5  j  2/n]  —  [{^1 5^1))  *“5  2/n)] 

Functionals 

map 

reduce 

directed-reduce 

/ *  t<2i,a2,...,a„]  =  [/(ai),/(a2),...,/(a„)] 

/  ©  [ai,a2,  =  cii  ©02  ©  ...  ©  an 

(/  ->  ©  e)[ai,02,  ...,a„]  =  (...((e  ©  ai)  ©  02)...  ©  a„) 

Operations  on  lists  are  known  to  be  homomorphisms  [2, 7]  and  incorporate  inherent  parallelism  and  a  fixed 
communication  pattern  [6].  map  is  completely  parallel  and  requires  no  communication.  It  can  be  implemented  as 
a  parallel  composition  of  n  functions  /,  each  on  an  individual  list  element,  reduce  can  be  evaluated  in  an  obvious 
tree-like  fashiop.  A  directed  reduce  can  be  implemented  as  a  pipeline,  or  a  sequential  composition  of  blocks  of 
(combinational)  circuits,  each  implementing  ®  on  a  corresponding  list  element  and  the  previous  result,  and 
passing  the  result  of  computations  to  its  right  neighbour.  A  set  of  implemetation  templates  for  list  operations 
is  given  in  Fig.  4.  Important  part  of  categorical  definition  of  list  operations  is  that  they  come  with  the  set  of 
algebraic  laws  which  are  used  in  transformational  program  derivation  [2, 5]. 


TEMMATfi  PC*  DtftRcrcn  RCniJO! 


>  .1  h  Jj  _  Vr 


COMPOSnWNOPDtSTRinimiAHD  MAP 


Fig.  4.  Implementation  templates  for  list  operations. 


3.1  n  —  to  —  2”  decoder 

Now  we  want  to  specify  a  general  n  -  to  —  2"  decoder.  Given  an  input  signal  x  and  a  number  s  =  sq  *  2'^  4- 
si  *  2^  +  ...  -f-  s„_i  *  2"  ^  represented  as  a  bit  list  [s„_i,.s„_2,  ...,So],  the  decoder  must  produce  2”  outputs 
b2»-i,  •  •  • , yo],  such  that  pi  =  x^{i  =  s). 

n  -  to  -  2"  function  can  be  represented  as  a  directed  reduce.  First,  bits  x  and  s„_i  are  used  by  a  1  -  to  -  2 
decoder  to  produce  a  pair  of  outputs,  a:&(=i  s„_i)  and  a:&(=o  Sn-i),  that  are  to  be  used  in  a  next  cascade 
(as  we  saw  in  a  2-to-4  example)  with  element  s„_2  of  the  input  list  distributed  among  these  partial  results, 
producing  4  new  bits,  which  in  their  turn  should  be  paired  with  the  consecutive  element  s„_3  of  the  input  list, 
etc.^  Hence,  n  —  to  —  2”  :  B  *  xB*  — ^  B*  is  defined  as 

n  —  to  —  2”([a;],  [s„_i , ...,  So])  =  (/  (/4f-  °  {MakeListo  d)  ^  odistr)[x])[sn-i,  ...,Sq\. 

Function  MakeList  makes  a  list  of  two  elements  from  a  pair:  MakeList{^x,y)  =  [®,y]  or,  in  a  more  concise 
notation,  MakeList  =  4f  o  ([.]  op^  x  [.]  op2),  where  pi  and  p2  are  projection  functions.  Function  d  is  a  1- 
to-2  decoder  defined  in  a  previous  section.  A  general  template  for  a  left  reduce  is  a  sequential  composition  of 
combinational  circuits,  each  of  which  performs  operation  (/  4f  o  {MakeList  od)*  odistr) .  Hence,  every  ”  ©  box” 
in  the  directed  reduce  template  in  Fig.  4  is  a  composition  of  templates  for  distr,  *  (map)  and  /  -H-  (flatten).  A 
straightforward  substitution  of  ©  boxes  for  templates  for  corresponding  operations  results  in  a  circuit  depicted 
in  Fig.  5. 

We  want  to  express  this  method  in  terms  of  list  functions.  Hence  we  will  be  using  lists  for  representation  of  partial 
results  as  well  as  for  representation  of  an  input  signal  s. 
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4  Discussion 

A  set  of  basic  algebras  for  bits,  characters,  short  and  long  integers,  etc.,  c^n  be  fully  specified  in  terms  of 
categories  with  products.  These  primitive  data  types  reflect  characteristics  of  the  basic  components  from  which 
to  build  a  particular  application.  These  basic  components  are  realized  in  a  straightforward  way  by  combinational 
circuits  and  implemented  by  blocks  of  FPGA  cells. ' 

However,  as  soon  as  we  need  delays,  combinational  circuits  alone  are  not  enough.  To  implement  a  delay,  we 
need  a  latch,  i.e.,  a  circuit  with  a.  feedback  loop.  To  reason  about  such  circuits  we  have  to  consider  at  any  moment 
the  state  of  the  whole  circuit.  Assuming  the  synchronous  model,  that  is  at  each  tick  of  a  clock  the  state  of  each 
wire  changes  according  to  a  nature  of  circuit  components,  we  need  functions  which  describe  the  general  change 
of  state.  Unfortunately,  we  cannot  do  it  in  a  category  with  products  only.  We  need  a  notion  of  control,  that  is 
decisions  on  which  operations  to  perform.  In  other  words,  we  need  categories  with  sums.  These  categories  should 
satisfy  the  distributive  laws  that  relate  sums  and  products  [8].  Of  course,  it  makes  the  design  and  analysis  of 
circuits  more  subtle  and  difficult.  Nevertheless,  while  we  stay  within  a  category  theory,  we  retain  many  useful 
features  -  operations  are  introduced  in  a  strict  orderly  fashion,  and  come  up  with  the  set  of  laws  that  can  be 
used  on  later  steps  of  development  and  optimization.  Hence  if  we  follow  the  advice  given  by  N.  Wirth  in  [9] 
and  restrict  circuit  design  to  combinational  circuits,  and  have  latches  and  registers  as  complete  parts,  so  that 
feedback  loops  exist  only  within  these  parts,  we  can  still  retain  much  of  the  simplicity  and  expressive  power  of 
homomorphisms . 

In  future,  we  want  to  extend  our  approach  to  design  and  analysis  of  any  synchronous,  sequential  circuit,  i.e., 
circuits  that  consist  of  combinational  circuits  and  registers,  the  latter  represent  a  state.  We  hope  to  develop  a 
compositional  approach,  similar  to  the  one  described  in  this  paper,  within  the  scope  of  the  distributive  category, 
so  that  any  state  machine  can  be  designed  and  analysed  in  a  concise  stepwise  manner. 
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Abstract.  Experimentation  in  sofhvare  engineering  is  important  but  difficult.  One  reason  it  is  so  difficult  is  that  there 
are  a  large  number  of  context  variables,  and  so  creating  a  cohesive  understanding  of  experimental  results  requires  a 
mechmism  for  motivating  studies  and  integrating  results.  This  paper  argues  for  the  necessity  of  a  framew'ork  for 
organizing  sets  of  related  studies.  With  such  a  framework,  experiments  can  be  viewed  as  part  of  common  families  of 
studies,  rather  than  being  isolated  events.  Common  families  of  studies  ean  contribute  to  important  and  relevant 
hypotheses  that  may  not  be  suggested  by  individual  experiments.  A  framework  also  facilitates  building  knowledge  in 
an  incremental  manner  through  the  replication  of  experiments  within  families  of  studies. 

Building  knowledge  in  this  way  requires  a  community  of  researchers  that  can  replicate  studies,  vary  context 
variables,  and  build  abstract  models  that  represent  the  common  observations  about  the  discipline.  This  paper  also 
presents  guidelines  for  lab  packages,  meant  to  encourage  and  support  replications,  that  encapsulate  materials, 
methods,  and  experiences  concerning  software  engineering  experiments. 


1  Introduction 

Experimentation  in  software  engineering  is  necessary.  Common  wisdom,  intuition,  speculation  and  proofs  of 
concepts  are  not  reliable  sources  of  credible  knowledge.  On  the  contrary,  progress  in  any  discipline  involves  building 
models  that  can  be  tested,  through  empirical  study,  to  check  whether  the  current  understanding  of  the  field  is  correct'. 
Progress  comes  when  what  is  actually  true  can  be  separated  from  what  is  only  believed  to  be  true.  To  accomplish  this, 
the  scientific  method  supports  the  building  of  knowledge  through  an  iterative  process  of  model  building,  prediction’ 
observation,  and  analysis.  It  requires  that  no  confidence  be  placed  in  a  theory  that  has  not  stood  up  to  rigorous  deductive 
testing  [21].  That  is,  any  scientific  theory  must  be  (1)  falsifiable,  (2)  logically  consistent,  (3)  at  least  as  predictive  as 
other  competing  theories,  and  (4)  its  predictions  have  been  confirmed  by  observations  during  tests  for  falsification. 
According,  to  Popper,  a  theory  can  only  be  shown  to  be  false  or  not  yet  false;  researchers  only  become  confident  in  a 


For  the  purpose  of  this  paper,  we  use  the  definitions  of  some  key  terms  from  [15]  and  [1],  An  empirical  study,  in  a  broad  sense,  is  an  act  or  operation 
for  the  purpose  of  discovering  something  unknown  or  of  testing  a  hypothesis,  involving  an  investigator  gathering  data  and  performing  anSysis  to 
detennine  what  the  data  mean.  This  covers  various  forms  of  research  strategies,  including  all  forms  of  experiments,  qualitative  studies,  surveys  and 

of  empirical  study  where  the  researcher  has  control  over  some  of  the  conditions  in  which  the  study  takes 
plaM  ^d  contol  over  the  independent  variables  being  studied;  an  operation  carried  out  under  controlled  conditions  in  order  to  test  a  hypothesis 
against  observation.  This  term  thus  includes  quasi-experiments  and  pre-experimental  designs 

ml*  phenomenon.  Any  theory  is  made  up  of  a  set  of  hypotheses.  A  itypoihesis  is  an  educated  guess  that  there 

can  relanon  among  constructs  of  theoretical  interest;  (2)  a  relation  between  a  construct  and  observable  indicators  (how  the  construct 

ft^ory  observed).  A  model  is  a  simplified  representation  of  a  system  or  phenomenon;  it  may  or  may  not  be  mathematical  or  even  formal;  it  can  be  a 
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theory  when  it  has  survived  numerous  attempts  made  at  its  falsification.  This  paradigm  is  a  necessary  step  for  ensuring 
that  opinion  or  desire  does  not  influence  knowledge. 

Experimentation  in  software  engineering  is  difflcult.  Carrying  out  empirical  work  is  complex  and  time 
consuming;  this  is  especially  true  for  software  engineering.  Unlike  manufacturing,  we  do  not  build  the  same  product, 
over  and  over,  to  meet  a  particular  set  of  specifications.  Software  is  developed  and  each  product  is  different  from  the 
last.  So,  software  artifacts  do  not  provide  us  with  a  large  set  of  data  points  permitting  sufficient  statistical  power  for 
confirming  or  rejecting  a  hypothesis.  Unlike  physics,  most  of  the  technologies  and  theories  in  software  engineering  are 
human-based,  and  so  variation  in  human  ability  fends  to  obscure  experimental  effects.  Human  factors  tend  to  increase 
the  costs  of  experimentation  while  making  it  more  difficult  to  achieve  statistical  significance. 

Abstracting  conclusions  from  empirical  studies  in  software  engineering  research  is  difficult.  An  important 
reason  why  experimentation  in  software  engineering  is  so  hard  is  that  the  results  of  almost  any  process  depend  to  a  large 
degree  on  a  potentially  large  number  of  relevant  context  variables.  Because  of  this,  we  cannot  a  priori  assume  that  the 
results  of  any  study  apply  outside  the  specific  environment  in  which  it  was  run.  For  isolated  studies,  even  if  they  are 
themselves  well-run,  it  is  difficult  to  understand  how  widely  applicable  the  results  are,  and  thus  to  assess  the  true 
contribution  to  the  field. 

As  an  example,  consider  the  following  study: 

•  Basili/Reiter.  This  study  was  undertaken  in  1976  in  order  to  characterize  and  evaluate  the  development 
processes  of  development  teams  using  a  disciplined  methodology.  The  effects  of  the  team  methodology  were 
contrasted  with  control  groups  made  up  of  development  teams  using  an  "ad  hoc"  development  strategy,  and 
with  individual  developers  (also  "ad  hoc").  Hypotheses  were  proposed:  that  (BRl)  a  disciplined  approach 
should  reduce  the  average  cost  and  complexity  (faults  and  rework)  of  the  process  and  (BR2)  the  disciplined 
team  should  behave  more  like  an  individual  than  a  team  in  terms  of  the  resulting  product.  The  study  addressed 
these  hjT3otheses  by  evaluating  particular  methods  (such  as  chief  programmer  teams,  top  down  design,  and 
reviews)  as  they  were  applied  in  a  classroom  setting.  [7] 

This  study,  like  any  other,  required  the  experimenters  to  construct  models  of  the  processes  studied,  models  of 
effectiveness,  and  models  of  the  context  in  which  the  study  was  run.  Replications  that  alter  key  attributes  of  these 
models  are  then  necessary  to  build  up  knowledge  about  whether  the  results  hold  under  other  conditions.  Unfortunately, 
in  software  engineering,  too  many  studies  tend  to  be  isolated  and  are  not  replicated,  either  by  the  same  researchers  or  by 
others.  Basili/Reiter  was  a  rigorous  study,  but  unfortunately  never  led  to  a  larger  body  of  work  on  this  subject.  The 
specific  experiment  was  not  replicated,  and  the  applicability  of  the  hypotheses  in  other  contexts  was  not  studied.  Thus  it 
was  never  investigated  whether  the  results  hold,  for  example: 

•  for  software  developers  at  different  levels  of  experience  (the  original  experiment  used  university  students); 

•  if  development  teams  are  composed  differently  (the  original  experiment  used  only  3-person  teams); 

•  if  another  disciplined  methodology  had  been  used  (i.e.,  were  the  benefits  observed  due  to  the  particular 
methodology  used  in  the  experiment,  or  would  they  be  observed  for  any  disciplined  methodology?). 


2  A  Motivating  Example:  Software  Reading  Techniques 

Yet  even  when  replications  are  run,  it's  hard  to  know  how  to  abstract  important  knowledge  without  a  framework 
for  relating  the  studies.  To  illustrate,  we  present  our  work  on  reading  techniques.  Reading  techniques  are  procedural 
techniques,  each  aimed  at  a  specific  development  task,  which  software  developers  can  follow  in  order  to  obtain  the 
information  they  need  to  accomplish  that  task  effectively  [2,  3].  We  were  interested  in  studying  reading  techniques  in 
order  to  determine  if  beneficial  experience  and  work  practices  could  be  distilled  into  procedural  form,  and  used 
effectively  on  real  projects.  We  felt  that  reading  techniques  were  of  relevance  and  value  to  the  software  engineering 
community,  since  reading  software  documents  (such  as  requirements,  design,  code,  etc.)  is  a  key  technical  activity. 
Developers  are  often  called  upon  to  read  software  documents  in  order  to  extract  specific  information  for  important 
software  tasks,  e.g.  to  read  a  requirements  document  in  order  to  find  defects  during  an  inspection,  or  an  Object-Oriented 
design  in  order  to  identify  reusable  components.  However,  while  developers  are  usually  taught  how  to  write  software 
documents,  the  skills  required  for  effecting  reading  are  rarely  taught  and  must  be  biiilt  up  through  experience.  In  fact, 
we  felt  that  research  into  reading  could  provide  a  model  for  how  to  effectively  write  documents  as  well:  by 
imderstanding  how  readers  perform  more  effectively  it  may  be  possible  to  write  documents  in  a  way  that  facilitates  the 
task. 
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However,  the  concept  of  reading  techniques  cannot  be  studied  in  isolation.  Like  any  other  software  process, 
reading  techniques  must  be  tailored  to  the  environment  in  which  they  are  run.  Our  aim  in  this  research  was  to  generate 
sets  of  reading  techniques  that  were  procedurally  defined,  tailorable  to  the  environment,  aimed  at  accomplishing  a 
particular  task,  and  specific  to  the  particular  document  and  notation  on  which  they  would  be  applied.  This  has  led  a 
series  of  studies  in  which  we  evaluated  the  following  types  of  reading  techniques; 

•  Defect-Based  Reading  (DBR)  focused  on  defect  detection  in  requirements,  where  the  requirements  were  expressed 
using  a  state  machine  notation  called  SCR  [13, 22]. 

•  Perspective-Based  Reading  (PBR)  also  focused  on  defect  detection  in  requirements,  but  for  requirements  expressed 
in  natural  language  [4,  16]. 

•  Use-Based  Reading  (UBR)  focused  on  anomaly  detection  in  user  interfaces  [27]. 

•  Second  Version  of  PBR  (PBR2)  consisted  of  new  techniques  that  were  more  procedurally-oriented  versions  of  the 
earlier  set  of  PBR  techniques.  In  particular,  we  made  the  techniques  more  specific  in  all  of  their  steps  [24]. 

•  Scope-Based  Reading  (SBR)  consisted  of  two  reading  techniques  that  were  developed  for  learning  about  an 
Object-Oriented  framework  in  order  to  reuse  it  [10, 23]. 

A  fi-amework  that  makes  explicit  the  different  models  used  in  these  experiments  would  have  many  benefits.  Such  a 
fi-amework  would  document  the  key  choices  made  during  experimental  design,  along  with  their  rationales.  The 
framework  could  be  used  to  choose  a  focus  for  future  studies:  i.e.,  help  determine  the  important  attributes  of  the  models 
used  in  an  experiment,  and  which  should  be  held  constant  and  which  varied  in  future  studies.  The  ultimate  objective  is 
to  build  up  a  unifying  theory  by  creating  a  list  of  the  specific  hypotheses  investigated  in  an  area,  and  how  similar  or 
different  they  all  are. 

Using  an  organizational  framework  also  allows  other  experimenters  to  understand  where  different  choices  could 
have  been  made  in  defining  models  and  hypotheses,  and  raises  questions  as  to  their  likely  outcome.  Because  these 
frameworks  provide  a  mechanism  by  which  different  studies  can  be  compared,  they  help  to  organize  related  studies  and 
to  tease  out  the  true  effects  of  both  the  process  being  studied  and  the  environmental  variables. 


3  The  GQM  Goal  Template  as  a  Tool  for  Experimentation 

Examples  of  such  organizational  frameworks  do  exist  in  the  literature,  e.g.  [9,  17,  20].  For  the  purpose  of  this 
paper  we  find  the  Goal/Question/Metric  (GQM)  Goal  Template  [8]  useful.  The  GQM  method  was  defined  as  a 
mechanism  for  defining  and  interpreting  a  set  of  operational  goals  using  measurement.  It  represents  a  top-down 
systematic  approach  for  tailoring  and  integrating  goals  with  models  of  software  processes,  products,  and  quality 
perspectives,  based  upon  the  specific  needs  of  a  project  and  organization. 

The  GQM  goal  template  is  a  tool  that  can  be  used  to  articulate  the  purpose  of  any  study.  It  ties  together  the 
important  models,  and  provides  a  basis  against  which  the  appropriateness  of  a  study's  specific  hypotheses,  and 
dependent  and  independent  variables,  may  be  evaluated.  There  are  five  parameters  in  a  GQM  goal  template: 

•  object  of  study:  a  process,  product  or  any  other  experience  model 

•  purpose:  to  characterize  (what  is  it?),  evaluate  (is  it  good?),  predict  (can  I  estimate  something  in  the  future?), 
control  (can  I  manipulate  events?),  improve  (can  I  improve  events?) 

•  focus:  model  aimed  at  viewing  the  aspect  of  the  object  of  study  that  is  of  interest,  e.g.,  reliability  of  the 
product,  defect  detection/prevention  capability  of  the  process,  accuracy  of  the  cost  model 

•  point  of  view:  e.g.,  the  perspective  of  the  person  needing  the  information,  e.g.,  in  theory  testing  the  point  of 
view  is  usually  the  researcher  trying  to  gain  some  knowledge 

•  context:  models  aimed  at  describing  environment  in  which  the  measurement  is  taken 

For  example,  the  goal  of  the  Basili/Reiter  study,  previously  described,  might  be  instantiated  as: 

To  analyze  the  development  processes  of  a  1)  disciplined-methodology  team  approach,  2)  ad  hoc  team 
approach,  and  3)  ad  hoc  individual  approach 
for  the  purpose  of  characterization  and  evaluation 
y/iUhxQspQcXXo  cost  and  complexity  (faults  and  rework)  of  the  process 
ihQ  pornt  of  View  of  tiiQ  developer  and  project  manager 
in  the  context  of  an  advanced  university  classroom 

Due  to  the  nature  of  software  engineering  research,  instantiated  goals  tend  to  show  certain  similarities.  The 
purpose  of  studies  is  often  evaluation;  that  is,  researchers  tend  to  study  software  technologies  in  order  to  assess  their 
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effect  on  development.  For  our  purposes,  the  point  of  view  can  be  considered  to  be  that  of  the  researcher  or  knowledge- 
builder.  While  studies  can  be  run  from  the  point  of  view  of  the  project  manager,  i.e.  requiring  some  immediate  feedback 
as  to  effects  on  effort  and  schedule,  published  studies  have  usually  undergone  additional,  post-hoc  analysis. 

The  remaining  fields  in  the  template  require  the  construction  of  more  complicated  models,  but  still  show  some 
similarities.  The  object  of  study  is  often  (but  not  always)  a  process;  researchers  are  often  concerned  with  evaluating 
whether  or  not  a  particular  development  process  represents  an  improvement  to  the  way  software  is  built.  (E.g.:  Does 
Object-Oriented  Analysis  lead  to  an  improved  implementation?  Does  an  investment  in  reviews  lead  to  less  buggy,  more 
reliable  systems?  Does  reuse  allow  quality  systems  to  be  built  more  cheaply?)  When  the  object  of  study  is  a  process,  the 
focus  of  the  evaluation  is  the  process'  effect.  The  experimenter  may  measure  its  effect  on  a  product,  that  is,  whether  the 
process  leads  to  some  desired  attribute  in  a  software  work  product.  Or,  the  experimenter  may  attempt  to  capture  its 
effect  on  people,  e.g.  whether  practitioners  were  comfortable  executing  the  process  or  found  it  tedious  and  infeasible. 
Finally,  the  context  field  should  include  a  large  number  of  environmental  variables  and  therefore  tends  to  exhibit  the 
most  variability.  Studies  may  be  run  on  students  or  experts;  under  time  constraints,  or  hot;  in  well-understood 
application  domains,  or  in  cutting-edge  areas.  There  are  numerous  such  variables  that  may  influence  the  results  of 
applying  a  technique. 

For  the  remainder  of  this  paper,  we  will  illustrate  our  conclusions  by  concentrating  on  studies  that  investigate 
process  characteristics  with  respect  to  their  effects  on  products.  A  GQM  template  for  this  class  of  studies  is: 

Analyze  processes  to  evaluate  their  effectiveness  on  a  product  from  the  point  of  view  of  the  knowledge  builder 
in  the  context  of  (a  particular  variable  setl. 

For  particular  studies  in  this  class,  constructing  a  complete  GQM  template  requires  making  explicit  the  process 
(object  of  study),  the  effect  on  the  product  (focus),  and  context  models  in  the  experiment.  Making  these  models  explicit 
is  necessary  in  order  to  understand  the  conditions  under  which  the  experimental  results  hold. 

For  example,  consider  the  GQM  templates  for  the  list  of  reading  technique  experiments  described  in  the  previous 
section.  There  are  many  ways  of  classifying  processes,  but  we  might  first  classify  processes  by  scope  as: 

•  Techniques  (processes  that  can  be  followed  to  accomplish  some  specific  task), 

•  Methods^  (processes  augmented  with  information  concerning  when  and  hpw  the  process  should  be  applied), 

•  Life  Cycle  Models  (processes  which  describe  the  entire  software  development  process). 

Each  of  these  categories  could  be  subdivided  in  turn.  The  set  of  techniques,  for  example,  could  be  classified  based 
on  the  specific  task  as:  Reading,  Testing,  Designing,  and  so  on.  We  have  found  it  helpful  to  think  of  the  range  of  values 
as  organized  in  a  hierarchical  fashion,  in  which  more  general  values  are  found  at  the  top  of  the  tree,  and  each  level  of 
the  tree  represents  a  new  level  of  detail.  (Figure  1) 

Selecting  a  particular  type  of  process  for  study,  our  GQM  template  then  becomes: 

Analyze  reading  techniques  to  evaluate  their  effectiveness  on  a  product  from  the  point  of  view  of  the 
knowledge  builder  in  the  context  of  a  particular  variable  set 


Life  Cycle  Model  Method  Technique 


Figure  1:  A  portion  of  the  hierarchy  of  possible  values  for  describing  software 
processes. 


The  reading  technique  experiments  were  concerned  with  studying  the  effect  of  the  reading  technique  on  a  product. 
So,  the  model  of  focus  needs  to  specify  both  how  effectiveness  is  to  be  measured  and  the  product  on  which  the 


^  The  definitions  of  "technique"  and  "method"  are  adapted  from  [5], 
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evaluation  is  performed. We  fmd  it  useful  to  divide  the  set  of  effectiveness  measures  into  analysis  and  construction 
measures,  based  on  whether  the  goal  of  the  process  is  to  analyze  intrinsic  properties  of  a  document  or  to  use  it  in 
building  a  new  system.  Each  of  these  categories  can  be  further  broken  down  into  more  specific  types  of  process  goals, 
for  which  different  effectiveness  measures  may  apply  (Fig.  2).  For  example,  the  effectiveness  of  a  process  for 
performing  maintenance  can  be  evaluated  by  how  that  process  effects  the  cost  of  making  a  change  to  the  system.  The 
effectiveness  of  a  process  for  detecting  defects  in  a  document  can  be  measured  by  the  number  of  faults  it  helps  find.  Of 
course,  many  more  measures  exist  than  will  fit  into  Figure  2.  For  instance,  rather  than  measure  the  number  of  faults  a 
defect  detection  process  yields,  it  might  be  more  appropriate  to  measure  the  number  of  errors^  or  the  amount  of  effort 
required,  among  other  things. 


Effectiveness 


faults  errors  anomalies 
detected  detected  detected 


Reuse  Maintenance 


\ 

Cost  of  Cost  of  Cost  of 

finding  integrating  making  a 

components  components  change 


Figure  2 :  A  portion  of  the  hierarchy  of  possible  values  for 
describing  the  effectiveness  of  software  processes 


Similarly,  a  software  document  can  be  classified  according  to  the  model  of  a  software  system  it  contains  (a 
relatively  well-defined  set)  and  further  subdivided  into  the  specific  notations  that  may  be  used  (Fig.3).  The  main 
purpose  of  organizing  the  possible  values  hierarchically  is  to  organize  a  conception  of  the  problem  space  that  can  be 
used  by  others  for  classifying  their  own  experiments.  The  actual  criteria  used  are  somewhat  subjective;  naturally  there 
^e  multiple  criteria  for  classifying  processes,  effectiveness  measures,  and  software  documents,  but  we  have  selected 
just  those  that  have  contributed  to  om  conception  of  reading  techniques. 


Document 


Flguird  3;  A  portion  of  tho  hloxarchy  of  possible  velues  for  describing  software 
documents . 


Thus  a  GQM  template  for  the  PER  experiment  could  be: 

reading  techniques  to  evaluate  their  ability  to  detect  defects  in  a  Requirements  Document  written 
jn  English  from  the  point  of  view  of  the  knowledge  builder  in  the  context  of  a  particular  variable  set . 

A  GQM  goal  is  not  meant  to  be  a  definitive  description,  but  reflects  the  interests  and  priorities  of  the  experimenter. 
If  we  were  to  stody  the  process  model  for  the  reading  techniques  in  each  experiment  in  more  detail,  we  would  see  that 
each  technique  is  tailored  to  a  specific  task  (e.g.,  analysis  or  construction,  etc.)  and  to  a  specific  document.  This  is  what 


’  Here  \ve  are  using  the  terms  "faults"  and  "errors"  according  to  the  IEEE  standard  definitions  [14],  in  which  "fault"  refers  to  defects  appearing  in 
some  artifact  while  error"  refers  to  an  underlying  human  misconception  that  may  be  translated  into  faults. 
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characterizes  the  reading  techniques  and  distinguishes  them  from  one  another.  Thus  the  process  goals  used  to  classify 
measures  of  effectiveness  in  Figure  2  can  be  easily  adapted  to  describe  the  processes  themselves  (Figure  4).  The 
distinction  between  analysis  and  construction  process  goals  can  apply  directly  to  processes.  That  is,  we  hypothesize  that 
analysis  tasks  differ  sufficiently  from  construction  tasks  that,  along  with  differences  in  the  way  they  may  be  evaluated 
for  effectiveness,  there  may  also  be  different  guidelines  used  in  their  construction.  Thus  figures  2  and  3  can  also  be 
mechanisms  for  identifying  process  model  attributes.  They  should  be  accounted  for  in  the  process  model  as  well  as  the 
effect  on  process. 


Process  Goal 


Analysis  Construction 


Defect  Usability  .  .  .  Reuse  Maintenance  ... 

Detection 

Figure  4:  A  portion  of  the  hierarchy  of  possible  values  for  describing  the  goal  of 
a  software  engineering  process. 

Thus  we  can  say  that  we  are: 

analyzing  a  reading  technique  for  the  purpose  of  evaluating  its  ability  to  detect  defects  in  a  natural  language 
requirements  document 

or  we  can  say  that  we  are: 

analyzing  a  reading  technique  tailored  to  defect  detection  in  natural  language  requirements  for  the  purpose  of 
evaluation. 

It  depends  on  whether  we  are  emphasizing  the  definition  of  the  process  or  of  its  effectiveness. 

In  linking  goal  templates  to  hypotheses,  we  can  think  of  the  process  model  (object  of  study)  as  the  independent 
variable,  the  effect  on  product  (focus)  as  the  dependent  variable,  and  the  context  variables  as  the  variables  that  exist  in 
the  environment  of  the  experiment.  The  differences  or  similarities  between  experimental  hypotheses  can  then  be 
described  in  terms  of  these  hierarchies  of  possible  values.  For  example,  consider  the  studies  of  DBR  and  PBR.  In  both 
cases,  the  process  model  was  focused  on  the  same  task  (defect  detection);  although  the  notation  differed,  both  were  also 
focused  on  the  same  document  (requirements).  If  all  other  attributes  for  process,  product,  and  context  models  were  held 
constant,  we  could  begin  to  think  of  hypotheses  at  a  higher  level  of  abstraction.  That  is,  instead  of  the  hypothesis: 

Subjects  using  a  reading  technique  tailored  to  defect  detection  in  natural  language  requirements  are 
more  effective  than  subjects  using  ad  hoc  techniques  for  this  task 

The  following  hypothesis  might  be  more  useful: 

Subjects  using  reading  techniques  tailored  to  defect  detection  in  requirements  are  more  effective  than 
subjects  using  ad  hoc  techniques  for  this  task. 

The  difference  between  these  hypotheses  is  that  the  focus  of  the  study  is  described  at  a  higher  level  of  abstraction 
for  the  second  hypothesis  (requirements)  than  for  the  first  (natural  language  requirements). 

This  difference  in  abstraction  makes  the  second  hypothesis  more  difficult  to  test.  In  fact,  probably  no  single  study 
could  ever  give  us  overwhelming  evidence  as  to  its  validity,  or  lack  thereof  Testing  the  second  hypothesis  would 
require  some  idea  of  what  types  of  requirements  notation  are  of  interest  to  practitioners.  Building  up  a  convincing  body 
of  evidence  requires  the  combined  analysis  of  multiple  studies  of  specific  reading  techniques  for  defect  detection  in 
requirements.  But  the  effort  required  to  formulate  the  hypothesis  and  begin  building  a  body  of  evidence  helps  advance 
the  field  of  software  engineering.  At  best,  the  evidence  can  lead  to  the  growth  of  a  body  of  knowledge,  containing  basic 
and  important  theories  underlying  some  aspect  of  the  field.  At  worst,  the  effort  spent  in  specifying  the  models  forces  us 
to  think  more  deeply  about  the  relevant  ways  of  characterizing  software  engineering  models  that  we,  as  researchers,  are 
implicitly  constructing  anyway. 

The  above  discussion  should  not  be  taken  to  imply  that  the  attributes  identified  in  Figures  1  through  4  are  the  only 
ones  that  are  important,  or  for  which  hierarchies  of  possible  values  exist.  To  choose  another  example,  in  specifying  the 
model  of  the  context  it  is  almost  always  important  to  characterize  the  experience  of  the  subjects  of  the  experiment.  The 
most  appropriate  way  of  characterizing  experience  depends  on  many  things;  two  possibilities  are  proposed  in  Figure  5. 
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Figure  5:  Two  possible  value  hierarchies  for  measuring  subject  experience. 


The  trees  shown  in  Figure  5  present  two  different  ways  of  characterizing  experience.  The  first  is  a  simpler  way  of 
characterizing  the  attribute  that  distinguishes  only  between  subjects  who  are  still  learning  software  engineering 
principles  versus  those  who  have  applied  them  on  real  projects.  The  second  hierarchy  attempts  to  place  finer 
distmctions  on  the  amount  of  experience  a  subject  has  applying  a  particular  process.  Each  may  be  appropriate  to 
different  circumstances. 


4  Replicating  Experiments 

In  preceding  sections  of  this  paper,  we  have  tried  to  raise  several  reasons  why  families  of  replicated  experiments 
are  necessary  for  building  up  bodies  of  knowledge  about  hypotheses.  Another  reason  for  running  replications  is  that 
they  can  increase  the  amount  of  confidence  in  results  by  addressing  certain  threats  to  validity;  Internal  validity  defines 
the  degree  of  confidence  in  a  cause-effect  relationship  between  factors  of  interest  and  the  observed  results,  while 
external  validity  defines  the  extent  to  which  the  conclusions  fi-om  the  experimental  context  can  be  generalized  to  the 
context  specified  in  the  research  hypothesis  [1 1].  In  this  section,  we  discuss  replications  in  more  detail  and  look  at  the 
practical  considerations  that  result. 

Our  primary  strategy  for  supporting  replications  in  practice  has  been  the  creation  of  lab  packages,  which  collect 
mformation  on  an  experiment  such  as  the  experimental  design,  the  artifacts  and  processes  used  in  the  experiment  the 
methods  used  during  the  experimental  analysis,  and  the  motivation  behind  the  key  design  decisions.  Our  hope  has  been 
that  the  existence  of  such  packages  would  simplify  the  process  of  replicating  an  experiment  and  hence  encourage  more 
replications  in  the  discipline.  Several  replications  have  been  carried  out  in  this  manner  and  have  contributed  to  a 
growing  body  of  knowledge  on  reading  techniques. 

4.1  Types  of  Replications 

Since  we  consider  that  replications  may  be  undertaken  for  various  reasons,  we  have  found  it  useful  to  enumerate 
the  vanous  reasons,  each  of  which  has  its  own  requirements  for  the  lab  package.  In  our  view  the  types  of  replications 

that  need  to  be  supported  can  be  grouped  into  3  major  categories: 

1.  Replications  that  do  not  vary  any  research  hypothesis.  Replications  of  this  type  vary  none  of  the  dependent  or 

independent  variables  of  the  original  experiment. 

1.1.  Strict  replications  (i.e.  replications  that  duplicate  as  accurately  as  possible  the  original  experiment)  These 
replications  are  necessary  to  increase  confidence  in  the  validity  of  the  experiment.  They  demonstrate  that  the 
results  from  the  onginal  experiment  are  repeatable,  and  have  been  reported  accurately  by  the  orieinal 
experimenters. 

1.2.  Rejftications  that  vary  the  manner  in  which  the  experiment  is  run.  These  studies  seek  to  increase  our 
confidence  m  experimental  results  by  addressing  the  same  problem  as  previous  experiments,  but  altering  the 
details  of  the  experiment  so  that  certain  internal  threats  to  validity  are  addressed.  For  example,  a  replication 
may  vary  the  order  of  activities  to  avoid  the  possibility  that  results  depend  not  on  the  process  used,  but  on  the 
order  m  which  activities  in  the  experiment  are  completed. 

The  attempt  to  compensate  for  threats  to  internal  validity  may  also  lead  to  other  types  of  changes.  For 
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example,  a  process  may  be  modified  so  that  the  researchers  can  assess  the  amount  of  process  conformance  of 
subjects.  Although  the  aim  of  the  change  may  have  been  to  address  internal  validity,  the  new  process  should 
be  evaluated  in  order  to  understand  whether  unanticipated  effects  on  process  effectiveness  have  resulted.  Thus 
such  a  replication  would  fall  into  the  second  major  category,  discussed  below. 

2.  Replications  that  vary  the  research  hypotheses.  Replications  of  this  type  vary  attributes  of  the  process,  product, 
and  context  models  but  remain  at  the  same  level  of  specificity  as  the  original  experiment. 

2.1.  Replications  that  vary  variables  intrinsic  to  the  object  of  study  (i.e.  independent  variables).  These 

replications  investigate  what  aspects  of  the  process  are  important  by  systematically  varying  intrinsic 

properties  of  the  process  and  examining  the  results.  This  type  of  experiment  requires  the  process  to  be 
supplied  in  sufficient  detail  that  changes  can  be  made.  This  implies  that  the  original  experimenters  must 
provide  the  rationales  for  the  design  decisions  made  as  well  as  the  finished  product.  For  example,  researchers 
may  question  whether  the  specificity  at  which  the  process  is  described  affects  the  results  of  applying  the 
process.  In  this  sense,  the  study  of  PBR2  may  be  seen  as  a  replication  of  the  study  of  PBR,  in  which  die  level 
of  specificity  of  the  process  was  varied  but  all  other  attributes  of  the  process  model  remained  the  same. 

2.2.  Replications  that  vary  variables  intrinsic  to  the  focus  of  the  evalpation  (i.e.  dependent  variables). 

Replications  of  this  type  may  vary  the  ways  in  which  effectiveness  is  measured,  in  order  to  understand  for 

what  dimensions  of  a  task  a  process  results  in  the  most  gain.  For  example,  a  replication  might  choose  another 
effectiveness  measure  fi-om  those  listed  in  Figure  2,  investigating  whether  a  defect  detection  process  is  more 
beneficial  for  finding  errors  than  faults.  Other  aspects  of  the  focus  model  might  be  varied  instead,  e.g.  a 
process  might  be  evaluated  on  a  document  of  the  same  type  but  different  notation  to  see  if  it  is  equally 
effective  (see  Figure  3). 

2.3.  Replications  that  Vary  context  variables  in  the  environment  in  which  the  solution  is  evaluated.  These 
studies  can  identify  potentially  important  environmental  factors  that  affect  the  results  of  the  process  under 
investigation  and  thus  help  understand  its  external  validity.  For  example,  replications  may  be  run  using  the 
same  process  and  product  models  as  the  original  experiment  but  on  professionals  instead  of  students  (see 
Figure  5)  to  see  if  the  same  results  are  obtained. 

3.  Replications  that  extend  the  theory.  These  replications  help  determine  the  limits  to  the  effectiveness  of  a  process, 
by  making  large  changes  to  the  process,  product,  and/or  context  models  to  see  if  basic  principles  still  hold.  We 
discussed  replications  in  the  previous  category  as  replacing  the  value  of  some  variable  (e.g.  document  on  which  the 
process  was  applied,  Figure  3)  with  another,  equally  specific  value  (e.g.  SCR  requirements  instead  of  English- 
language  requirements).  Replications  in  this  category,  however,  can  be  thought  of  as  replacing  an  attribute  of  a 
process,  product,  or  context  model  with  a  value  at  a  higher  level  of  abstraction  (i.e.  from  a  higher  level  in  the 
hierarchy).  Again  using  Figure  3,  researchers  may  choose  to  study  whether  a  type  of  process  is  applicable  to 
requirements  documents  in  general,  rather  than  limiting  their  scope  to  a  specific  kind.  The  type  of  hypotheses 
associated  with  such  replications  was  discussed  in  section  3. 

4.2  Implications  for  Lab  Package  Design 

In  software  engineering  research,  there  has  been  a  movement  toward  the  reuse  of  physical  artifacts  and  concrete 
processes  between  experiments.  This  is  indeed  a  useful  beginning.  The  cost  of  an  experiment  is  greatly  increased  if  the 
preparation  of  multiple  artifacts  is  necessary.  Creating  artifacts  which  are  representative  of  those  used  in  real 
development  projects  is  difficult  and  time  consuming.  Reusing  artifacts  can  thus  reduce  the  time  and  cost  needed  for 
experimentation.  A  more  significant  benefit  is  that  reuse  allows  the  opportunity  to  build  up  knowledge  about  the  actual 
use  of  particular,  non-trivial  artifacts  in  practice.  Thus  replications  (and  experimentation  in  general)  could  be  facilitated 
if  there  were  repositories  of  reusable  artifacts  of  different  types  (e.g.  requirements)  which  have  a  history  of  reuse  and 
which,  therefore,  are  well  understood.  (A  model  for  such  repositories  could  be  the  repository  of  system  architectures 
[12],  where  the  relevant  attributes  of  each  design  in  the  repository  are  known  and  described.) 

A  first  step  towards  this  goal  is  the  construction  of  web-based  laboratory  packages.  At  the  most  basic  level,  these 
packages  allow  an  independent  experimenter  to  download  experimental  materials,  either  for  reuse  or  for  better 
understanding.  In  this  way,  these  packages  support  strict  replications  (as  defined  in  section  4.1),  which  require  that  the 
processes  and  artifacts  used  in  the  original  experiment  be  made  available  to  independent  researchers. 

However,  web-based  lab  packages  should  be  designed  to  support  more  sophisticated  types  of  replications  as  well. 
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For  example,  packages  should  assist  other  experimenters  in  understanding  and  addressing  the  threats  to  validity  in  order 
to  support  replications  that  vary  some  aspects  of  the  experimental  setup.  Due  to  the  constraints  imposed  by  the  setting  in 
which  software  engineering  research  is  conducted,  it  is  almost  never  possible  to  rule  out  every  single  threat  to  validity. 
Choosing  the  least  bad”  set  of  threats  given  the  goal  of  the  experiment  is  necessary.  Lab  packages  need  to 
acknowledge  this  fact  and  make  the  analysis  of  the  constraints  and  the  threats  to  validity  explicit,  so  that  other  studies 
may  use  different  experimental  designs  (that  may  have  other  threats  to  validity  of  their  own)  to  rule  out  these  threats. 

Replications  that  seek  to  vary  the  detailed  hypotheses  have  additional  requirements  if  the  lab  package  is  to  support 
them  as  well.  For  example,  in  order  for  other  kperimenters  to  effectively  vary  attributes  of  the  object  of  study,  the 
original  process  must  be  explained  in  sufficient  detail  that  other  researchers  can  draw  their  own  conclusions  about  key 
variables.  Since  it  is  unreasonable  to  expect  the  original  experimenters  to  determine  all  of  the  key  variables  a  priori,  lab 
packages  must  provide  rationales  for  key  experimental  context  decisions  so  that  other  experimentalists  can  determine 
feasible  points  of  variation  of  interest  to  themselves.  Similarly,  lab  packages  must  specify  context  variables  in  sufficient 
detail  that  feasible  changes  to  the  environment  can  be  identified  and  hypotheses  made  about  their  effects  on  the  results. 

Finally,  in  order  to  build  up  a  body  of  knowledge  about  software  engineering  theories,  researchers  should  know 
which  experiments  have  been  run  that  offer  related  results.  Therefore,  lab  packages  for  related  experiments  should  be 
linked,  in  order  to  collect  different  experiments  that  address  different  areas  of  the  problem  space,  and  contribute 
evidence  relevant  to  basic  theories.  The  web  is  an  ideal  medium  for  such  packages  since  links  can  be  added 
dyn^ically,  pointing  to  new,  related  lab  packages  as  they  become  available.  Thus  it  is  to  be  hoped  that  lab  packages 
are  “living  documents”  that  are  changed  and  updated  to  reflect  our  current  understanding  of  the  experiments  they 
describe. 


Lab  packages  have  been  our  preferred  method  for  facilitating  the  abstraction  of  results  and  experiences  from  series 
of 'well-designed  studies.  Interested  readers  are  referred  to  existing  examples  of  lab  packages:  [25,  26].  By  collecting 
detailed  information  and  results  on  specific  experiments,  they  summarize  our  knowledge  about  specific  processes 
They  record  the  design  and  analysis  methods  used  and  may  suggest  new  ones.  Additionally,  by  linking  related  studies 
they  can  help  experimenters  understand  what  factors  do  or  do  not  impact  effectiveness. 


4.3  The  Experimental  Community 

A  group  of  researchers,  from  both  industry  and  academia,  has  been  organized  since  1993  for  the  purpose  of 
facilitating  the  replication  of  experiments.  The  group  is  called  ISERN,  the  International  Software  Engineering  Research 
Network,  and  includes  members  in  North  America,  Europe,  Asia,  and  Australia.  ISERN  members  publish  common 
technical  reports,  exchange  visitors,  and  organize  annual  meetings  to  share  experiences  on  software  engineering 

experimentation  .  They  have  begun  replicating  experiments  to  better  understanding  the  success  factors  of  inspection  and 
reading.  ^ 

The  Empirical  Software  Engineering  journal  has  also  helped  build  an  experimental  community  by  providing  a 
forum  for  publishing  descriptions  of  empirical  studies  and  their  replications.  An  especially  noteworthy  aspect  of  the 
journal  is  that  it  is  open  to  publishing  replicated  studies  that,  while  rigorously  planned  and  analyzed,  yield  unexpected 
results  that  did  not  confirm  the  original  study.  Although  it  has  traditionally  been  difficult  to  publish  such 
“unsuccessful”  studies  in  the  software  engineering  literature,  this  knowledge  must  be  made  available  if  the  community 
is  to  build  a  complete  and  unbiased  body  of  knowledge  concerning  software  technologies. 

5  Conclusions 

The  above  discussion  leads  us  to  propose  that  the  following  criteria  are  necessaiy  before  we  can  begin  to  build  up 
comprehensive  bodies  of  knowledge  in  areas  of  software  engineering: 

1.  Hypotheses  that  are  of  interest  to  the  software  engineering  community  and  are  written  in  a  context  that  allow  for  a 
well  defined  experiment; 

2.  Context  variables,  suggested  by  the  hypotheses,  that  can  be  changed  to  allow  for  variation  of  the  experimental 
design  (to  make  up  for  validity  threats)  and  the  context  of  experimentation; 

3.  A  sufficient  amount  of  information  so  that  the  experiment  can  be  replicated  and  built  upon;  and 

4.  A  community  of  researchers  that  understand  experimentation,  the  need  for  replication,  and  are  willine  to 

collaborate  and  replicate.  * 


*  More  information  is  available  at  the  URL  http://wwwagse.informatik.uni-kl.de/lSERN/isem.htm! 
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With  respect  to  the  Basili/Reiter  study  introduced  in  section  1,  we  can  note  that  while  it  satisfied  criteria  1  and  3,  it 
failed  with  respect  to  criteria  2  and  4.  It  was  not  suggested  by  the  authors  that  other  researchers  might  vary  the  design  or 
manipulate  the  processes  or  criteria  used  for  evaluation  (although  the  analysis  of  the  data  was  varied  in  a  later  study 
[6]).  Nor  was  there  a  community  of  researchers  willing  to  analyze  the  hypotheses  even  if  suggestions  for  replication  had 
been  made. 

In  contrast,  the  set  of  experiments  on  reading,  discussed  in  a  working  group  at  the  1997  annual  meeting  of  ISERN 
[1 8],  is  an  example  that  we  have  built  up  a  body  of  knowledge  by  independent  researchers  working  on  different  parts  of 
the  problem  and  exposing  their  conclusions  to  different  plausible  rival  hypotheses.  We  have  shown  in  this  paper  that 
experimental  constraints  in  software  engineering  research  make  it  very  difficult,  and  even  impossible,  to  design  a 
perfect  single  study.  In  order  to  rule  out  the  threats  to  validity,  it  is  more  realistic  to  rely  on  the  "parsimony"  concept 
rather  than  being  frustrated  because  of  trying  to  completely  remove  them,  This  appeal  to  parsimony  is  based  on  the 
assumption  that  the  evidence  for  an  experimental  effect  is  more  credible  if  that  effect  can  be  observed  in  numerous  and 
independent  experiments  each  with  different  threats  to  validity  [11]. 

A  second  conclusion  is  that  empirical  research  must  be  a  collaborative  activity  because  of  the  huge  number  of 
problems,  variables,  and  issues  to  consider.  This  complexity  can  be  faced  with  extensive  brainstorming,  carefully 
designing  complementary  studies  that  provide  coverage  of  the  problem  and  solution  space,  and  reciprocal  verification. 

It  is  our  contention  that  interesting  and  relevant  hypotheses  can  be  identified  and  investigated  effectively  if 
empirical  work  is  organized  in  the  form  of  families  of  related  experiments.  In  this  paper,  we  have  raised  several  reasons 
why  such  families  are  necessary: 

•  To  investigate  the  effects  of  alternative  values  for  important  attributes  of  the  experimental  models; 

•  To  vary  the  strategy  with  which  detailed  hypotheses  are  investigated; 

•  To  make  up  for  certain  threats  to  validity  that  often  arise  in  realistically  designed  experiments. 

Discussion  within  the  experimental  community  is  also  needed  to  address  other  issues,  such  as  what  constitutes  an 
“acceptable”  level  of  confidence  in  the  hypotheses  that  we  address  as  a  community.  By  running  carefully  designed 
replications,  we  can  address  threats  to  validity  in  specific  experiments  and  accumulate  evidence  about  hypotheses. 
However,  we  are  unaware  of  any  useful  and  specific  guidelines  that  concern  the  amount  of  evidence  that  must  be 
accumulated  before  conclusions  can  confidently  be  drawn  from  a  set  of  related  experiments,  in  spite  of  the  existence  of 
specific  threats.  More  discussion  within  the  empirical  software  engineering  community  as  to  what  constitutes  a 
sufficient  body  of  credible  knowledge  would  be  of  benefit. 

Building  up  a  body  of  knowledge  from  families  of  experiments  has  the  following  benefits  for  the  software 
engineering  researcher: 

•  It  allows  the  results  of  several  experiments  to  be  combined  in  order  to  build  up  our  knowledge  about  software 
processes. 

•  It  increases  the  effectiveness  of  individual  experiments,  which  can  now  contribute  to  answering  more  general  and 
abstract  hypotheses. 

•  It  offers  a  framework  for  building  relevant  practical  software  engineering  knowledge,  organized  around  the  GQM 
goal  template  or  another  framework  from  the  literature. 

•  It  provides  a  way  to  develop  and  integrate  laboratory  manuals,  which  can  facilitate  and  encourage  the  types  of 
replications  that  are  necessary  to  expand  our  knowledge  of  basic  principles. 

•  It  helps  generate  a  community  of  experimenters,  who  understand  the  value  of,  and  can  carry  out,  the  needed 
replications. 

The  ability  to  carry  out  families  of  replications  has  the  following  benefits  for  the  software  engineering  practitioner: 

•  It  offers  some  relevant  practical  SE  knowledge;  fully  parameterizing  process,  product,  and  context  models  allows  a 
better  understanding  of  the  environment  in  which  the  experimental  results  hold. 

•  It  provides  a  better  basis  for  making  judgements  about  selecting  process,  since  practitioners  can  match  their 
development  context  to  the  ones  under  which  the  processes  are  evaluated. 

•  It  shows  the  importance  of  and  ability  to  tailor  “best  practices”,  that  is,  it  shows  how  software  processes  can  be 
altered  by  meaningful  manipulation  of  key  variables. 

•  It  provides  support  for  defining  and  documenting  processes,  since  running  related  experiments  assists  in 
determining  the  important  process  variables. 

•  It  allows  organizations  to  integrate  their  experiences  by  making  explicit  the  ways  in  which  experiences  differ  (i.e. 
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what  the  relevant  process,  product,  and  context  models  are)  or  are  similar,  and  allowing  the  abstraction  of  basic 
principles  from  this  information. 
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Abstract.  In  this  paper  we  study  some  natural  problems  related  to  specifying  sets  of  words  and  trees  by 
patterns.  ' 


1  Introduction 

Patterns  are  probably  the  most  simple  and  natural  way  to  specify  non-trivial  families  of  combinatorial  structures. 
Abstractly,  let  5  be  a  class  of  combinatorial  structures  with  a  substructure  relation  (such  as  graphs,  trees,  strings, 
etc.).  Usually,  given  Q  we  can  define  in  a  natural  way  a  notion  of  pattern,  interpreted  as  an  underspecified 
structure  of  G,  that  is  a  structure  with  some  “unspecified  parts”.  A  pattern  defines  a  set  of  instances  which  are 
structures  obtained  by  instantiating  the  pattern’s  unspecified  parts  by  other  structures.  For  example,  in  case 
of  graph  structures,  patterns  could  be  defined  as  graphs  with  some  “meta-nodes”  which  can  be  instantiated  by 
other  graphs. 

Using  these  informal  definitions,  we  now  introduce  central  notions  of  this  paper.  For  a  set  S  of  patterns, 
we  denote  by  Inst{S)  the  set  of  structures  which  are  instances  of  patterns  of  S.  By  Cont(S)  we  denote  the  set 
of  structures  which  have  a  substructure  in  Inst{S).  In  the  above  example  of  graphs,  if  S'  is  a  set  of  patterns 
(graphs  with  meta-nodes  ),  Inst{S)  is  the  set  of  instances  of  patterns  from  S  and  Cont{S)  could  be  defined  as 
the  set  of  graphs  having  a  subgraph  that  is  an  instance  of  a  pattern  of  S.  We  will  also  study  the  complements 
of  sets  Inst{S)  and  Cont(S),  defined  by  7nst(5)  =  g\  Inst{S)  and  Cont(S)  =  g\  Cont{S). 

In  this  paper  we  consider  two  structures,  which  are  probably  the  most  widely  used  data  structures  in 
computer  science:  words  and  trees.  We  will  define  the  notion  of  pattern  for  each  of  these  structures  and  we  will 
compare  the  complexity  of  different  natural  problems  related  to  patterns  in  the  cases  of  words  and  trees.  In  this 
perspective,  we  survey  various  known  results  and  give  several  new  ones. 

2  Words,  Trees  and  Patterns 

Let  us  start  with  basic  definitions.  Given  a  finite  alphabet  A  of  letters,  words  over  A  are  defined  in  the  usual  way 
as  finite  sequences  of  letters.  A*  stands  for  the  set  of  words  over  A.  From  algebraic  point  of  view,  words  over  A 
are  elements  of  the  firee  monoid  generated  by  A.  Word  patterns  over  A  are  defined  as  words  over  alphabet  AuX, 
where  X  is  an  infinite  alphabet  of  variables.  For  example,  v  abaababaabaab  is  a  word  over  the  alphabet  (a,  6} 
and  assuming  that  x,y  £  X,  abaxbayb,xabax,xaxxaxax  are  patterns  over  {a,b}.  A  variable  occurring  more 
than  once  in  the  pattern  is  called  non-linear,  otherwise  it  is  linear.  A  subword  of  a  word  is  a  fragment  of  its  letter 
sequence.  For  example,  baab  is  a  subword  of  v  and  abba  is  not,  A  substitution  is  a  morphism  o  :  (A  U  X)*  — >  A* 
such  that  (t(o)  =  a  for  all  a  £  A.  A  substitution  is  non-erasing  if  a(x)  e,  where  e  is  the  empty  word,  and 
erasing  otherwise.  A  word  w  £  A  is  an  instance  of  a  pattern  p  £  (A  U  X)*  ii  w  =  (x(p)  for  some  substitution  a. 
In  this  case  we  say  also  that  p  matches  w.  A  substitution  can  be  simply  seen  as  a  mapping  replacing  variable 
occurrences  in  the  pattern  by  words  such  that  the  occurrences  of  the  same  variable  are  replaced  by  the  same 
word.  For  example,  the  word  v  is  an  instance  of  each  of  the  three  patterns  above. 

A  tree  is  a  well-formed  expression  over  a  signature  S  of  function  symbols,  where  each  symbol  is  indexed 
by  an  integer  number,  called  its  arity.  For  example,  u  =  f{f{f{a,a),h{a)),h{a))  is  a  tree  over  the  signature 
^  —  {f jh,a},  where  symbols  /, h, a  have  arity  2,1,0  respectively.  The  set  of  trees  over  X  is  denoted  by  T{S). 
Prom  algebraic  point  of  view,  T{S)  is  a  free  A'-algebra  generated  by  E.  Thus,  we  are  dealing  with  node-labeled 
trees  representing  first-order  terms  over  a  given  signature.  We  will  use  the  words  tree  and  term  interchangeably. 
Clearly,  we  assume  that  the  signature  contains  at  least  one  0-arity  (constant)  symbol,  otherwise  the  set  of  terms 
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is  empty.  A  tree  pattern  is  a  tree  over  E\J  X,  where  X  is  an  infinite  set  of  0-arity  symbols  of  variables.  Thus, 
f  {x,h{y)),  f{f{f{y,a),x),x)  are  tree  patterns  over  {f,h,a},  where  x.y  are  variables.  A  subtree  of  a  tree  t  is 
a  subexpression  of  t.  In  other  words,  a  subtree  of  t  is  a  tree  occurring  at  some  node  of  t.  The  subtrees  of  u 
are  f{f{f{a,  a),  h(a)),  h(a)),  /(/(a,  a),  h(a)),  f{a,  a),  h{a)  and  a.  Note  that  h{a)  and  a  have  several  occurrences 
in  u.  A  substitution  is  a  homomorphism  a  :  T{S  U  X)  T{S)  such  that  a(a)  =  a  for  each  constant  a  from 
E.  Again,  t  —  a{p)  for  some  term  t,  pattern  p  and  substitution  a,  then  t  is  said  to  be  an  instance  of  p, 
and  p  is  said  to  match  t.  Similar  to  words,  a  substitution  replaces  variables  in  patterns  by  trees  such  that  the 
same  variable  is  replaced  by  the  same  term.  For  example,  term  u  is  an  instance  of  both  patterns  f{x,  h{y))  and 
/(/(/(y,  a),  a;),  x),  but  is  not  an  instance  of /(/(a;,  a;),  h(a)). 

Note  that  words  can  be  represented  as  trees  in  at  least  two  ways.  One  way  is  to  map  each  letter  to  a  distinct 
unary  symbol,  and  to  add  to  the  signature  one  constant  symbol.  Then  a  word  can  be  naturally  represented  by 
a  non-branching  tree.  However,  to  represent  a  pattern  consistently,  we  need  to  introduce  variables  at  internal 
nodes  (second-order  variables)  which  does  not  fit  to  our  framework.  Another  way  is  to  map  each  letter  to  a 
corresponding  constant  symbol  and  use  one  additional  binary  symbol  for  concatenation.  In  this  case,  however, 
one  word  is  represented  by  several  trees,  due  to  the  associativity  property  of  concatenation.  In  general,  words 
can  be  seen  as  trees  over  one  associative  function  symbol.  We  will  see  in  this  paper  that  this  associativity 
property  makes  many  problems  on  words  much  more  difficult  than  their  counterparts  for  trees. 

3  Problems 

We  now  state  the  problems  we  will  address  in  this  paper.  We  assume  that  we  are  given  a  set  S  of  word  (resp. 
tree)  patterns.  As  defined  in  Introduction,  Inst{S)  denotes  the  set  of  word  (resp.  tree)  instances  of  patterns  of 
S,  and  Cont{S)  denotes  the  set  of  words  (trees)  having  respectively  a  subword  (subtree)  that  is  an  instance 
of  a  pattern  from  S.  If  S  consists  of  a  single  pattern  p,  we  will  write  Inst(p)  and  Cont(p)  as  a  short-hand  for 
Inst({p})  and  Cont{{p}). 

We  are  interested  in  the  following  problems  for  both  words  and  trees.  Below  u  is  a  word  (resp.  tree),  p  is  a 
word  (resp.  tree)  pattern,  and  5  is  a  set  of  patterns. 

Pl.l  u  e  Inst(p)? 

P1.2  u  6  Cont(p)? 

P2.1  is  Inst(S)  a  finite  set? 

P2.2  is  Instls)  a  regular  set? 

P3  Inst(p)  C  Inst{S)? 

P4  Instjp)  C  Cont{S)l 
P5.1  is  Cont{S)  a  finite  set? 

P5.2  is  Cont{S)  a  regular  set? 

These  questions  are  standard  language-theoretic  problems.  Pl.l  and  PI. 2  are  membership  problems  for  Inst- 
and  (7ont-languages.  Since  Inst{S)  and  Cont{S)  are  generally  infinite,  it  makes  sense  to  ask  if  these  sets  are 
co-finite.  This  justifies  problems  P2.1  and  P5.1.  Problems  P2.2  and  P5.2  ask  whether  Inst{S)  (respectively 
Cont{S))  is  a  regular  set  of  words  (trees).  If  the  notion  of  regular  word  set  (language)  is  well-known,  the  notion 
of  regular  tree  language  is  probably  less  standard.  For  readers  who  are  not  familiar  with  regular  tree  languages, 
we  refer  to  books  [GS84,NP92].  Finally,  problems  P5  and  P4  are  also  usual  language  inclusion  questions,  as 
Inst{S)  =  Upssinstip),  and  Inst{S)  C  L  iff  for  all  p  G  S',  Instep)  CL. 

4  The  Tree  Case 

We  now  start  with  the  tree  case  and  survey  what  is  known  here  about  the  questions  above.  This  will  motivate 
our  study  and  will  allow  to  compare  these  results  with  their  counterparts  for  the  word  case. 

Pl.l  is  a  trivial  problem  for  the  tree  case.  It  asks  whether  a  term  is  an  instance  of  a  tree  pattern,  which  can 
be  easily  done  in  linear  time.  It  is  sufficient  to  check  if  the  pattern  coincides  with  the  term  at  all  non-variable 
positions,  and  check  that  the  subterms  of  the  term  corresponding  to  distinct  occurrences  of  the  same  variable 
in  the  pattern  coincide.  Clearly,  this  can  be  done  in  time  0(|u|  -f  |p|). 

P1.2  is  the  subterm  matching  problem  which  has  numerous  applications  in  functional  and  logic  programming, 
automated  deduction,  term  rewriting  and  other  areas  related  to  symbolic  computation.  The  problem  consists 
of  testing  whether  a  given  pattern  occurs  in  a  given  tree,  that  is  matches  one  of  its  subtrees.  Usually,  one  wants 
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also  an  algorithm  to  find  all  such  subtrees,  and  not  only  to  test  if  there  is  one.  The  restricted  version  of  this 
problem,  when  the  pattern  contains  only  linear  variables,  is  known  under  the  name  tree  matching.  In  early  80’s, 
a  simple  practical  solution  has  been  proposed  [H082].  More  recently,  a  series  of  work  has  been  done  to  find 
the  most  efficient  (in  the  worst-case)  algorithm  for  tree  matching.  We  refer  to  the  latest  achievement  [CHI99] 
which  proposes  an  0(nlog®n)  deterministic  algorithm,  where  n  is  the  size  of  the  tree  (assumed  to  be  bigger 
than  the  size  of  the  pattern).  The  algorithm  (as  well  as  previously  proposed  theoretically  efficient  algorithms)  is 
however  rather  complicated  and  difficult  to  implement,  and  the  problem  of  designing  an  efficient  and  practical 
tree  matching  algorithm  is  still  on  the  agenda.  Now,  if  a  pattern  contains  non-linear  variables,  we  can  preprocess 
the  subject  tree  by  indexing  its  nodes  in  such  a  way  that  if  the  subtrees  rooted  in  two  nodes  are  the  same,  then 
these  nodes  have  the  same  index.  This  preprocessing  can  be  done  in  linear  time  (under  the  assumption  that 
the  signature  has  a  constant  size)  by  a  bottom-up  traversal  of  the  tree.  Then  we  can  “forget”  about  repeated 
variables  in  the  pattern  and  consider  all  variable  nodes  to  be  labeled  by  distinct  variables.  We  then  run  a  tree 
matching  algorithm  for  linear  patterns,  and  check,  each  time  we  find  an  occurrence  of  the  linear  pattern,  if  the 
subterms  corresponding  to  occurrences  of  the  same  variable  in  the  original  pattern  are  equal  (by  looking  at 
their  indexes).  This  comparison  takes  time  proportional  to  the  maximal  number  of  occurrences  in  the  original 
pattern  (0(|p|)  in  the  worst  case),  which  introduces  a  \p\  factor  with  respect  to  the  theoretic  complexity  of  linear 
pattern  matching.  We  refer  to  [RR92]  for  a  detailed  algorithm  of  subterm  matching  in  presence  of  non-linear 
variables. 

Let  us  now  turn  to  problem  P2.1,  and  consider  a  generalization  of  it.  Instead  of  asking  whether  Inst{S) 
is  finite,  we  ask  if  Inst{S)  can  be  itself  represented  as  Inst{3')  for  some  finite  set  of  patterns  S'.  Such  a  set 
S'  is  called  a  complement  representation  of  S  [KP98].  Again,  non-linear  variables  in  patterns  of  S  play  an 
important  role.  Consider  the  set  5  =  {h{x),f{h{x),y)}  over  the  signature  {f,h,a}  as  above.  Then  the  set 
S'  =  {a,fia,x),f{f{x,y),z)}  is  a  complement  representation  of  5.  One  can  generalize  this  and  prove  that  if  all 
patterns  in  the  set  are  linear,  a  finite  complement  representation  of  this  set  can  be  constructed.  However,  one 
can  prove  that  the  set  S  =  {f{x,x)}  does  not  have  a  finite  complement  representation.  The  exhaustive  analysis 
of  the  situation  has  been  given  in  [LM87].  The  main  result  can  be  stated  as  follows. 

Theorem  1  ([LM87]).  A  set  of  patterns  S  has  a  finite  complement  representation  iff  there  exists  a  set  of 
linear  patterns  Sun  such  that  Inst{S)  =  Inst{Sun).  Moreover, 

—  if  such  a  set  Sun  exists,  it  can  be  obtained  by  instantiating  the  non-linear  variables  in  the  patterns  of  S  by 

terms, 

-  the  property  of  having  a  finite  complement  representation  is  decidable. 

Let  us  illustrate  Theorem  1  by  an  example.  Consider  the  set  S  =  {a,  f{x,h{y)),f{x,x),  f{x,f{y,z))},  still 
over  the  signature  {f,h,a}.  This  set  contains  a  non-linear  term  f{x,x).  However,  a  simple  analysis  shows 
that  f{x,x)  can  be  replaced  by  f{a,a)  without  changing  the  set  of  instances.  Thus,  Inst{S)  =  Inst{Siin), 
where  Sun  is  a  set  of  linear  patterns  obtained  from  5  by  substituting  a  to  a:  in  the  term  f{x,x).  Fur¬ 
thermore,  as  Siin  contains  only  linear  patterns,  a  complement  representation  of  Sun  can  be  constructed; 
Siin  /(h(2;), o), /(/(x, 2/), a)}.  Theorem  1  asserts  that  this  example  is  typical:  if  a  finite  complement 

exists,  the  set  is  “linearizable” ,  that  is  non-linear  variables  can  be  replaced  by  terms  without  changing  the  set 
of  instances.  The  decidability  of  this  property,  stated  in  Theorem  1,  means  that  a  bound  on  the  size  of  terms 
replacing  non-linear  variables  can  be  effectively  computed. 

Recently,  the  study  of  finite  complement  representations  has  received  a  new  impulse  [GP99,Pic99],  motivated 
by  its  applications  in  different  areas,  and  in  particular  in  logic  programming.  In  [Pic99],  it  has  been  proved  that 
testing  if  a  given  set  has  a  finite  complement  representation  (see  Theorem  1)  is  co-NP-coraplete. 

Coming  back  to  problem  P2.1,  to  check  if  Inst(S)  is  finite,  we  first  check,  according  to  Theorem  1,  if  S  has 
a  finite  complement  representation.  If  the  answer  is  positive,  we  compute  such  a  representation.  If  all  patterns 
in  the  representation  are  terms  (i.e.  do  not  contain  variables),  then  Inst{S)  is  finite.  Otherwise,  if  at  least  one 
pattern  has  a  variable,  InstiS)  is  infinite.  This  shows  that  P2.1  is  in  co-NP.  The  NP-hardness  of  P2.1  follows 
fi-om  [KNRZ91],  where  it  was  proved  that  deciding  if  InstiS)  =  0,  is  co-NP-complete.  An  easy  modification  of 
the  hardness  part  of  this  proof  shows  that  P2.1  is  co-NP-hard,  and  therefore  co-NP-complete. 

Theorem  1  gives  actually  an  answer  to  problem  P2.2  too.  It  is  an  easy  exercise  to  prove  that  if  a  set  S 
contains  only  linear  patterns,  InstiS)  is  a  regular  tree  language  [GS84,NP92].  Thus,  when  a  set  is  “linearizable” 
in  the  sense  of  Theorem  1,  the  set  of  instances  is  regular.  On  the  other  hand,  if  a  set  is  not  linearizable,  it  can 
be  shown  using  a  pumping  lemma  argument  that  the  set  of  instances  is  not  regular.  This  is  however  not  easy 
to  prove,  but  follows  from  the  work  [Kuc91]  that  we  will  survey  below.  We  summarize  the  discussion  in  the 
following  statement. 
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Proposition  1.  In  the  tree  case,  P2.1  and  P2.2  are  co-NP-complete  problems. 

Now  let  us  skip  problem  P3  for  a  moment  an(i  turn  to  problem  P4  which  has  now  a  more-than-ten-years 
history.  The  problem,  known  under  the  name  of  ground  reducibility  problem,  has  attracted  a  lot  of  attention  in 
the  area  of  term  rewriting  [DJ90]  because  of  its  application  to  automated  inductive  proofs  [JK89].  The  problem 
consists  of  testing  if  all  instances  of  a  given  tree  pattern  p  have  a  subtree  matched  by  one  of  the  patterns  of 
a  given  set  S.  Once  again,  non-linear  variables  in  patterns  of  S  make  the  problem  much  more  difficult.  In  the 
middle  and  late  80 ’s,  several  authors  observed  that  the  problem  is  decidable  if  patterns  of  S  only  contain  linear 
variables.  The  problem  was  first  proved  decidable  in  the  general  case  by  Plaisted  [Pla85],  and  later  by  other 
authors  independently  [KNZ87,Com88].  Recently,  the  problem  wns  shown  to  be  EXPTIME-complete  [CJ97]. 

Problem  P3  can  be  expressed  in  terms  of  P4  in  the  following  way.  Assume  we  have  a  pattern  p  and  a  set 
of  patterns  5,  and  we  want  to  test  whether  Inst{p)  C  Inst{S).  First  delete  from  S  those  patterns  which  do 
not  have  the  same  root  symbol  as  the  root  symbol  of  p  (obviously,  these  patterns  cover  no  instance  of  p).  Then 
choose  a  new  symbol  a  and  replace  the  root  symbol  in  p  and  in  all  remaining  patterns  in  5  by  a.  Let  p'  and  S' 
be  the  resulting  pattern  and  set  respectively.  It  can  be  shown  that  Inst{p)  C  Inst{S)  iff  Inst(p')  C  Cont{S'). 
The  latter  property,  which  is  a  special  instance  of  ground  reducibility,  can  be  expressed  as  the  so  called  sufficient 
completeness  property  for  specifications  with  free  constructors  (see  [KNR.Z91])..  Deciding  this  property  has  been 
proved  co-NP-complete  in  [KNRZ91]. 

Proposition  2.  In  the  tree  case,  P.3  and  P4  are  bbth  decidable  problems.  P3  is  co-NP-complete  and  P4  is 
EXPTIME-complete. 

Finally,  let  us  turn  to  problems  5.1  and  5.2.  Problem  5.1  has  been  proved  decidable  in  [Pla85,KNZ87]. 
Concerning  Problem  5.2,  the  following  Theorem  has  been  proved  in  [Kuc91]. 

Theorem  2.  For  a  set  of  patterns  S,  Cont(S)  is  a  regular  tree  language  iff  there  exists  a  set  o/ linear  patterns 
Siin  such  that  Cont{S)  =  Cont{Siin).  Moreover, 

-  if  such  a  set  Sun  exists,  it  can  be  obtained  by  instantiating  the  non-linear  variables  in  the  patterns  of  S  by 

terms. 

Theorem  2  is  a  lifting  of  Theorem  1  from  the  set  of  instances  Inst{S)  to  the  set  Cont(S)  of  terms  containing 
instances  of  S  as  subterms.  The  latter  case  is  however  much  more  difficult,  and  the  proof  of  Theorem  2  used 
a  non-constructive  combinatorial  argument,  based  on  Ramsey  Theorem.  Therefore,  no  effective  bound  on  the 
size  of  terms  to  be  substituted  for  the  non-linear  variables,  resulted  from  the  proof,  and  the  decidability  of  the 
regularity  of  Cont{S)  remained  an  open  problem.  This  problem:,  considered  important  in  the  area  of  rewriting, 
has  appeared  in  the  list  of  major  open  problems  in  rewriting  in  [DJK91].  Soon  after,  the  regularity  of  Cont{S) 
has  been  proved  decidable  by  three  groups  of  authors  [KT92,VG92,HH92].  The  results  of  [KT95]  provided  also 
a  new  proof  of  the  decidability  of  problem  5.1,  and  even  gave  an  effective  bound  on  the  size  of  Cont{S)  in  the 
case  it  is  finite.  We  then  conclude  this  section  with  the  following 

Proposition  3.  In  the  tree  case,  P5.1  and  P5.2  are  both  decidable  problems. 

5  The  Word  Case 

The  overview  of  the  tree  case  given  in  the  previous  section  shows  that  all  the  problems  are  decidable,  though 
the  complexity  of  some  of  them  appears  to  be  high.  In  this  section  we  study  these  problems  in  the  word  case 
and  see  that  most  of  them,  and  even  some  restricted  versions  of  them,  turn  out  to  be  undecidable.  We  also 
analyze  the  complexity  of  these  problems  in  the  case  of  linear  patterns. 

We  first  remark  that  in  the  tree  case,  Cont{S)  is  a  “meta-notion”  with  respect  to  Inst{S),  due  to  the  fact 
that  the  notion  of  subtree  cannot  be  expressed  by  means  of  patterns,  as  only  first-order  variables  are  allowed 
in  patterns.  In  contrast,  in  the  word  case  Cont[S)  can  be  expressed  in  terms  of  Inst{S): 

Cont{S)  —  Inst[{xpy,xp,py,p\p  e  S  and  x,y  do  not  occur  in  p]) 

This  implies  that,  in  contrast  to  the  tree  case,  the  problem  for  Cont{S)  is  simpler  than  its  counterpart  for 
Inst{S).  In  particular,  if  a  problem  is  decidable  for  Inst{S),  it  is  also  decidable  for  Cont{S).  On  the  other  hand, 
if  a  problem  is  undecidable  for  Inst{S),  the  undecidability  of  its  counterpart  for  Cont(s)  may  be  harder  to 
prove.  We  will  face  this  situation  later  in  this  section. 
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Note  another  difference  with  the  tree  case:  in  contrast  to  trees,  we  may  allow  variables  in  word  patterns  to  be 
substituted  by  the  empty  word.  This  gives  rise  to  two  cases  depending  of  whether  this  possibility  is  allowed  or 
not.  Following  Kari  et  al.  [KMPS95],  we  call  these  cases  erasing  [E-case  for  short),  if  substituting  by  the  empty 
word  is  allowed,  and  non-erasing  [NE-case),  if  it  is  not  allowed.  We  will  generally  speak  about  the  NE-case, 
unless  the  E-case  is  explicitly  mentioned. 

An  early  result  of  Angluin  [AngSO]  asserts  that  problem  Pl.l  is  NP-complete.  This  implies  that  P1.2  is  also 
NP-complete,  as  w  €  Inst{p)  iff  #«;#  G  Cont{#p#)  where  #  is  a  fresh  letter.  This  NP-completeness  result 
immediately  shows  that  the  word  case  appears  to  be  much  more  difficult,  as  Pl.l  and  PI. 2  are  polynomial 
problems  in  the  tree  case,  of  low  polynomial  degree.  However,  if  pattern  p  is  linear,  Pl.l  and  P1.2  can  be  solved 
in  linear  time,  as  they  actually  reduce  to  the  well-known  string  matching  problem,  and  can  be  solved,  e.g.,  by 
the  Knuth-Morris-Pratt  algorithm  [CR95].  In  the  general  case,  the  naive  algorithm  solving  Pl.l  is  in  0(|'u;|'^) 
(respectively  2),  where  A  is  the  number  of  distinct  variables  in  p.  N6raud  [Ner95]  showed 

how  this  complexity  can  be  slightly  reduced  (roughl)^,  the  exponent  can  be  decreased  by  2)  and  obtained  some 
specialized  efficient  algorithms  for  P1.2  for  the  cases  of  low  ^  (1  or  2). 

Proposition  4.  In  the  word  case,  problems  Pl.l  and  P1.2  are  NP-complete.  Both  problems  can  be  solved  in 
linear  time  if  pattern  p  is  linear. 

The  difficulty  of  matching  problems  Pl.l  in  the  case  of  words  can  be  also  illustrated  by  the  fact  that  if 
a  word  w  is  matched  by  a  pattern  p,  that  is  u;  =  a(j)),  then  substitution  a  does  not  have  to  be  unique.  For 
example,  pattern  xy  can  match  a  word  w  in  (|m|  —  1)  different  ways,  corresponding  to  the  factorizations  of 
w  into  two  parts.  It  is  easy  to  see  that  many  patterns  admit  this  situation  (e.g.  all  linear  patterns),  but  not 
all  of  them  -  for  example,  patterns  x,  xx  (and  more  generally,  one-variable  patterns)  have  a  unique  way  to 
match  a  word.  Formally,  a  pattern  p  is  called  non-ambiguous  if  there  is  a  unique  way  for  p  to  match  each 
word  of  Inst{p),  and  ambiguous  otherwise.  The  ambiguity  of  patterns  was  studied  by  Mateescu  and  Salomaa 
{MS94].  They  introduced  the  notion  of  degree  of  ambiguity  of  a  pattern  p  defined  as  the  maximal  number  of 
ways  for  p  to  match  a  word  from  Inst(p)  provided  this  number  is  finite;  otherwise  the  degree  of  ambiguity  is 
00.  It  is  easy  to  exhibit  patterns  with  the  degree  of  ambiguity  1  or  00,  and  much  more  difficult  with  a  finite 
degree  of  ambiguity  different  from  1.  In  [MS94],  it  was  shown  that  pattern  p  =  xabxbcayabcy  has  the  degree  of 
ambiguity  2.  For  exarnple,  there  are  two  ways  for  p  to  match  the  word  caabcabcaabcbcabcabcbc,  and  any  word 
from  Inst{p)  is  matched  by  p  in  at  most  two  ways.  The  authors  also  found  a  pattern  of  degree  of  ambiguity  3, 
^d  by  some  composition  technique,  patterns  of  any  degree  2'^3".  However,  they  state  it  as  an  open  question 
if  every  finite  degree  of  ambiguity  is  realizable  by  some  pattern.  The  decidability  status  of  determining  if  the 
degree  of  ambiguity  of  a  pattern  is  finite,  is  also  open. 

Let  us  now  turn  to  problem  P3.  A  striking  result  has  been  proved  in  [JSSY93]:  inclusion  Inst(p)  C  Inst{S) 
is  undecidable  even  if  S  consists  of  a  single  pattern.  This  contrasts  to  the  fact  that  the  equivalence  problem 
Inst(j>i)  =  Inst[p2)  is  trivial:  the  equivalence  holds  iff  pi  and  p2  are  equal  modulo  a  variable  renaming.  The 
latter  is  however  true  only  in  the  NE-case,  and  for  the  E-case  the  decidability  status  of  the  equivalence  problem 
Inst\jpi)  —  Inst[p2)  is  open.  We  also  point  out  to  paper  [Fil88]  for  some  results  about  the  inclusion  problem 
Instipi)  Q  Inst(p2)  in  the  E-  and  NE-case. 

Proposition  5.  In  the  word  case,  problem  P3  is  undecidable  even  if  S  consists  of  a  single  pattern. 

Formally,  the  undecidability  result  of  [JSSY93]  for  problerh  P3  does  not  imply  the  undecidability  of  problem 
P4  (see  the  discussion  in  the  beginning  of  this  section).  Problem  P4  has  been  studied  in  [KR95b],  where  it  has 
been  proved  undecidable. 

Proposition  6.  In  the  word  case,  problem  P4  is  undecidable. 

An  interesting  feature  of  the  proof  of  [KR95b]  is  that  it  implies  that  the  problem  Inst{p)  C  Ccmt{S)  remains 
undecidable  if  p  has  a  very  simple  form,  namely  the  form  axa,  where  a  is  a  letter  and  x  a  variable.  It  seems 
very  difficult  (if  at  all  possible)  to  further  simplify  p.  We  will  come  back  to  this  issue  below. 

Based  on  the  proof  of  the  result  of  [KR95b],  we  now  establish  a  new  result. 

Theorem  3.  In  the  word  case,  problem  P2.1  is  undecidable. 

Proof.  We  give  a  very  general  idea  of  the  proof.  To  reconstruct  the  details,  the  reader  is  referred  to  [KR95b]. 

First,  we  review  the  proof  of  [KR95b]  of  Proposition  6.  To  show  that  Inst[axa)  C  Inst[S)  is  undecidable, 
the  construction  of  5  is  based  on  the  following  idea.  The  instances  of  p  =  axa  are  assumed  to  encode  runs  of 
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a  given  deterministic  Minsky  (two-register)  machine  M  on  a  given  data  d.  Patterns  of  S  are  designed  in  such 
a  way  that  every  instance  of  p  which  does  not  encode  a  correct  run  of  machine  M  on  data  d,  contains  some 
pattern  from  S.  To  put  it  in  another  way,  an  instance  of  p  which  does  not  contain  any  pattern  of  S,  must  encode 
a  correct  finite  run  of  machine  M  on  data  d.  Therefore,  there  exists  an  instance  of  p  which  does  not  contain  an 
instance  of  5  iff  M  halts  on  d,  which  is  an  undecidable  property. 

To  prove  Theorem  3,  we  modify  the  proof  as  follows.  We  modify  the  set  of  patterns  S  in  such  a  way  that  S 
encodes  only  a  Minsky  machine  M,  and  does  not  specify  any  input  data  d.  Assume  that  S'  is  the  modified  set 
of  patterns.  Consider  now  the  set  of  patterns 

S  =  {axla  &  A,  a  /  a}  U  {xa\a  G  A,  a  a}  U 

{xpy\p  e  S'  arid  x,y  do  not  occur  in  p},  (1) 

where  a  is  the  same  letter  as  in  the  pattern  p  above.  Prom  the  previous  discussion,  it  is  clear  that  the  words 
which  are  in  Inst{S)  are  words  of  the  form  awa,  which  are  not  instances  of  S'.  By  construction  of  S',  these 
are  words  which  encode  a  correct  finite  run  of  the  machine  M  on  some  input  data.  Since  it  is  undecidable  if  a 
machine  stops  on  a  finite  number  of  input  data,  it  is  undecidable  if  the  set  Inst{S)  is  finite  or  not. 

The  decidability  status  of  Problem  P2.2  is  open  [KMPS95].  The  inverse  problem,  whether  a  given  regular 
language  is  expressible  as  Inst{S)  is  also  not  known  to  be  decidable.  It  is  also  open  if  it  is  decidable  for  a 
language  Inst{S)  to  be  context-free.  However,  it  was  proved  in  [KMPS95]  that  it  is  undecidable  if  a  given 
context-free  language  is  expressible  as  Inst{S). 

Let  us  now  consider  problem  P5.1.  The  proof  of  Theorem  3  above  may  suggest  that  P5.1  is  not  so  much 
different  fi-om  P2.1  and  must  be  also  undecidable  by  a  similar  proof.  Indeed,  all  “important”  patterns  occur  in 
the  third  set  of  (1),  and  patterns  in  the  first  and  the  second  sets  are  extremely  simple  -  they  consists  of  a  single 
letter  followed  or  preceded  by  a  variable.  However,  these  “extremely  simple”  patterns  play  a  crucial  role  as  they 
actually  specify  the  first  and  last  letter  in  the  words  of  the  language,  which  is  necessary  for  an  undecidability 
proof  (see  [KR95b]). 

The  decidability  status  of  Problem  5.1  is  open.  Actually,  it  is  the  most  general  version  of  the  famous 
avoidability  problem.  The  avoidability  problem  was  studied  in  the  word  corribinatorics  under  a  very  restricted 
form  -  when  S  contains  a  single  pattern  p,  and  moreover,  p  contains  only  variables  and  no  letters.  However, 
even  in  this  restricted  form  the  problem  turns  out  to  be  extremely  difficult. 

It  is  not  known  if  testing  the  finiteness  of  Cont{p)  is  decidable  or  not.  The  author  of  [Cur93]  offered  100  US 
dollars^  for  a  solution  of  this  problem. 

A  pattern  p  is  called  unavoidable,  {blocking  according  to  the  terminology  of  [Zim84])  if  Cont{p)  is  finite, 
and  avoidable  otherwise.  Clearly,  p  is  avoidable  iff  there  exists  an  infinite  word  which  does  not  coritain  (finite) 
subwords  which  are  instances  of  p. 

Interestingly,  a  study  of  avoidability  is  historically  at  the  origin  of  word  combinatorics  and  formal  lan¬ 
guage  theory.  Back  to  the  beginning  of  the  century.  Axel  Thue  obtained  his  famous  construction  of  an  infinite 
square- free  word  on  the  three-letter  alphabet  and  an  infinite  cube- free  word  on  the  two-letter  alphabet.  In  the 
terminology  of  pattern  avoidance,  a  square-free  and  cube-free  word  is  a  word  which  does  not  contain  respectively 
the  pattern  xx  and  xxx.  Trivially,  xx  is  unavoidable  on  two  letters  and  xxx  is  unavoidable  on  one  letter.  A 
pattern  which  is  avoidable  on  four  letters  but  not  on  three  letters  has  been  described  in  [BEM79].  No  pattern 
is  known  which  is  avoidable  on  k  letters  but  unavoidable  on  fc  -  1  letters  for  >  4. 

The  above  discussion  shows  that  the  size  of  the  alphabet  may  be  crucial  in  avoiding  patterns.  We  refer 
to  [Cas94]  for  a  survey  of  the  state-of-the-art  in  pattern  avoidance.  A  key  result  in  the  area  is  an  algorithm 
proposed  independently  in  [BEM79,Zim84],  which  decides  if  there  exists  an  alphabet  on  which  a  given  pattern 
can  be  avoided.  However,  as  was  mentioned  above,  it  is  not  known  if  for  a  fixed  alphabet  one  can  decide,  given 
a  pattern,  if  it  is  avoidable  on  this  alphabet. 

The  rest  of  the  paper  is  devoted  to  analyzing  some  of  our  problems  in  case  the  set  S  consists  of  linear  patterns. 
We  already  mentioned  that  problems  Pl.l  and  P1.2  can  be  efficiently  solved  if  p  is  a  linear  pattern.  For  the 
other  problems  we  will  see  that  although  they  become  decidable  in  the  linear  case,  they  remain  untractable. 

Note  that  if  S  consists  of  linear  patterns,  the  languages  Inst{S)  and  Cont{S)  are  regular  languages  specified 
by  a  regular  expression  of  the  form 

\Jti{A*)wnA*Wi2...A*WikM*), 

^  2278.78  russian  rubles  as  for  February  12,  1999 


(2) 
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where  Wij  s  are  words  and  parenthesis  indicate  that  A*  may  or  may  not  occur  in  the  beginning  and  the  end 
of  the  expression.  Thus,  problems  P2.2  and  P5.2  are  always  positively  answered.  Note  also  that  inclusion  and 

equivalence  of  regular  languages  specified  by  general  regular  expressions  is  a  PSPACE-complete  problem  (cf 
[GJ79]).  ^  V 

In  [KR95a]  problems  P4  and  P5.1  have  been  studied  under  the  condition  that  the  patterns  of  S  are  linear. 
As  for  P4,  it  has  been  proved  that  it  is  decidable  in  this  case,  regardless  if  p  is  linear  or  not.  If  p  is  restricted 
to  be  linear  too,  the  problem  has  been  proved  to  be  co-NP-complete  [KR95a].  The  exact  complexity  of  the  case 
when  patterns  of  S  are  linear  but  pattern  p  is  not,  is  not  known  to  us.  However,  if  the  maximal  number  of 
occurrences  of  a  variable  is  bounded,  the  problem  remains  co-NP-complete. 

Proposition  7.  Problem  P4  of  testing  Inst(p)  C  Cont(^S)  is  decidable  if  S  consists  of  linear  patterns.  If  p  is 
linear  in  addition,  the  problem  is  co-NP-complete. 

It  was  also  proved  in  [KR95a]  that  if  S  is  restricted  to  contain  linear  patterns  only,  problem  P5.1  is  co-NP- 
complete  too. 

To  move  on,  we  need  to  sketch  the  co-NP-completeness  proofs  from  paper  [KR95a].  Consider  problem  P4 
for  the  case  that  pattern  p  and  all  patterns  of  S  are  linear.  The  co-NP-hardness  of  this  problem  is  easy  to 
show.  We  refer  to  [KR95a]  for  the  reduction  from  MONOTONE-ONE-IN-THREE-SAT.  However,  proving  the 
membership  in  co-NP  represents  a  non-trivial  part.  It  amounts  to  show  that  if  Inst{p)  g  C<mt{S),  there  is 
an  instance  of  p  of  size  polynomial  on  (|5|  -h  |p|)  which  does  not  contain  any  pattern  from  S.  Of  course,  the 
language  Cont{S)  and  its  complement  Cont{S)  are  regular,  as  Cont{S)  has  form  (2).  The  proof  of  [KR95a] 
consisted  of  defining  a  compact  deterministic  finite  automaton  (DFA)  for  these  languages  verifying  the  following 
key  property:  although  the  total  size  (number  of  states)  of  this  automaton  is  exponential  in  |5|,  the  length  of 
the  longest  loop-free  path  from  the  initial  to  the  finite  state  is  of  polynomial  length.  We  refer  to  [KR95a]  for 
further  details. 

This  property  of  the  automaton  allowed  to  show  that  in  case  Inst(p)  g  Cont(S),  the  minimal  size  of  an 
instance  of  p  which  is  not  in  Cont(S)  has  a  size  polynomial  on  |5|.  Similarly,  if  Cont{S)  is  finite  (problem 
P5.1),  we  can  give  a  polynomial  bound  on  the  length  of  words  in  ContiS).  This  provides  a  key  argument  in  the 
co-NP-completeness  proof. 

Here  we  use  this  argument  to  show  the  co-NP-completeness  of  two  other  problems  -  P3  (in  case  p  is  a  linear 
pattern)  and  P2.1. 

Since  P3  is  a  more  general  problem  than  P4  in  the  word  case,  P4  is  co-NP-hard  if  p  is  a  linear  pattern. 
Similarly,  P2.1  is  more  general  than  P5.1  and  is  then  also  co-NP-hard.  To  prove  that  both  of  them  are  in  co-NP, 
we  use  an  adaptation  of  the  deterministic  automaton  construction  from  [KR95a]  from  the  language  Cont{S)  to 
Inst{S).  We  skip  the  details  of  the  construction  which  would  require  us  too  much  space,  and  summarize  the 
results  in  the  following  statement. 

Theorem  4.  Assuming  a  linear  pattern  p  and  a  set  of  linear  patterns  S,  problems  P2.1,  P3,  P4  and  P5.1  are 
co-NP-complete. 

Finally,  for  a  linear  pattern  p,  following  [Shi82],  we  can  build  a  DFA  recognizing  Inst(p)  in  polynomial 
(linear)  time:  if  p  =  {xo)uiXi . . .  Xn-i  (xn)  (Ui  e  A+,Xi  £  X) ,  the  idea  is  to  build  DFA’s  Di , . . . ,  Z)„  recog¬ 
nizing  respectively  Cont{ui), ...,  Cont{un),  and  then  to  identify  the  final  state  of  Di  with  the  initial  state  of 
Di+i.  This  construction  implies,  in  particular,  that  for  the  special  case  of  P3  and  P4  where  p  is  linear  and  S 
consists  of  a  single  linear  pattern,  a  solution  can  be  obtained  in  polynomial  time:  the  question  Inst{p)  C  Inst{p') 
is  equivalent  to  the  emptiness  of  the  language  /nst(p')  n  Inst(p)  whose  DFA  is  easily  derived  in  polynomial 
(quadratic)  time  [HU79]. 

Proposition  8.  Assuming  a  linear  pattern  p  and  S  =  {p'}  with  p'  a  linear  pattern,  PS  and  P4  can  be  checked 
in  polynomial  time. 


6  Conclusions 

In  this  paper  we  forniulated  several  language-theoretic  problems  which  are  meaningful  for  any  combinatorial 
structure  equipped  with  a  notion  of  pattern  and  a  substructure  relation.  We  then  studied  the  algorithmic 
complexity  of  those  problems  for  two  particular  structures  -  trees  over  a  finite  signature  and  words  over  a  finite 
alphabet.  It  turns  out  that  the  instances  of  these  problems  for  v/ords  and  trees  cover  a  large  area  of  research, 
including  seemingly  quite  unrelated  subareas.  Some  problems  on  trees  have  been  studied  in  term  rewriting 


Kucherov  G.,  Rusinowitch  M.  Patterns  in  Words  versus  Patterns  in  Trees:  A  Brief  Survey  and  New  Results  209 

theory,  with  relation  to  the  theory  of  tree  languages.  Some  other  problems,  such  as  tree  matching,  have  received 
much  attention  in  the  area  of  algorithm  development.  Applied  to  words,  those  problems  have  been  studied  in 
the  area  of  word  combinatorics  and  formal  language  theory,  including  the  recent  research  stream  on  pattern 
languages.  Again,  the  matching  problem  for  words  has  been  subject  of  intensive  studies  in  the  algorithmics  area. 
We  found  it  interesting  that  all  these  problems  can  be  expressed  uniformly  as  classical  problems  on  languages 
specified  by  patterns.  ^ 

We  attempted  to  give  a  brief  survey  of  considered  problems,  putting  the  stress  on  comparing  the  tree  and 
the  word  case.  Moreover,  we  gave  several  new  results  for  the  word  case.  We  showed  that  all  problems  are  easier 
on  the  tree  case  than  their  counterparts  for  the  word  case.  In  particular,  except  for  the  matching  problem,  all 
problems  are  decidable  in  the  tree  case  and  undecidable  in  the  word  case.  For  the  word  case,  we  gave  a  special 
attention  to  the  linear  case,  where  the  problems  become  decidable  but,  as  we  have  showed,  remain  of  high 
algorithmic  complexity. 
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Abstract.  Monads  are  a  technique  widely  used  in  functional  programming  languages  to  address  many 
different  problems.  This  paper  presents  extensions,  a  functional-logic  programming  technique  that  consti¬ 
tutes  an  alternative  to  monads  in  several  situations.  Extensions  permit  the  definition  of  easily  reusable 
functions  in  the  same  way  as  monads,  but  are  based  on  simpler  concepts  taken  from  logic  programming, 
and  hence  they  lead  to  more  appealing  and  natural  definitions  of  types  and  functions.  Moreover,  extensions 
are  compatible  with  interesting  features  typical  of  logic  programming,  like  multiple  modes  of  use,  while 
monads  are  not. 

1  Introduction 

Functional-Logic  programming,  FLP  in  short,  aims  to  integrate  of  functional  and  logic  programming,  allowing 
the  use  of  techniques  from  both  paradigms  into  the  same  declarative  framework  (see  [Han94]  for  a  survey). 
Moreover,  the  combination  of  ideas  of  the  two  worlds  gives  rise  to  new  features  specific  to  FLP.  This  work 
should  be  seen  as  a  contribution  in  this  direction,  for  it  presents  a  new  technique,  the  extensions,  that  can  be 
used  as  an  alternative  to  the  functional  technique  of  monads  when  programming  in  a  functional-logic  language. 

The  concept  of  monad  comes  from  category  theory,  and  it  has  been  widely  used  in  functional  programming 
to  structure  functions,  pointing  out  the  essence  of  the  algorithms  represented  while  concealing  the  data  flow 
and  the  associated  computations  [Wad90,Wad92,Wad95]. 

In  several  FLP  frameworks  such  as  Escher  [Llo95],  Curry  [Han98]  or  our  working  language,  TOy  [CLS97], 
monads  can  be  used  directly,  yielding  the  same  benefits  as  in  the  case  of  functional  programming.  However, 
FLP  has  a  wider  range  of  programming  mechanisms,  including  logical  variables,  and  it  should  be  questioned 
whether  it  is  possible  to  define  a  specific  FLP  technique  to  address  the  same  kind  of  problems  from  a  different 
point  of  view.  In  the  rest  of  the  paper  we  describe  such  an  alternative,  the  FLP  extensions.  Although  lacking  the 
theoretical  background  and  wide  range  of  applications  of  monads,  extensions  present  some  specific  advantages, 
such  as: 

•  Extensions  can  replace  monads  in  several  different  situations,  allowing  the  same  expressiveness  but  using  much 
simpler  concepts. 

•  Multiple  modes  of  use  are  allowed  by  extensions,  which  is  not  so  easy  to  achieve  when  defining  monads  in  an 
FLP  context. 

•  In  the  case  of  adding  new  features  to  functions,  monads  enforce  the  evaluation  of  both  the  old  and  the  new 
values  simultaneously.  Conversely,  extensions  can  use  the  new  feature  only  where  it  is  required,  thus  avoiding 
unnecessary  computations. 

2  The  FLP  framework:  A  succinct  description  of  T Oy 

All  the  programs  in  the  next  sections  are  written  in  the  purely  declarative  functional-logic  language  TOy, 
which  is  a  concrete  realization  of  CRWL,  a  theoretical  framework  for  declarative  programming  (see  [GHh-96]). 
We  present  here  only  the  subset  of  the  language  relevant  to  this  work.  A  more  complete  description' and  a 
number  of  representative  examples  can  be  found  in  [CLS97]. 

A  TOy  program  consists  of  datatype,  type  alias,  infix  operator  definitions,  and  rules  for  defining  functions. 
Syntax  is  mostly  borrowed  from  Haskell  [HAS97],  with  the  remarkable  exception  that  variables  begin  with 
upper-case  letters  whereas  constructor  and  function  symbols  use  lower-case. 

•  Work  partially  supported  by  the  Spanish  CICYT  (project  TIC98-0445-C03-02/97  ’’TREND”)  and  the  ESPRIT  Work¬ 
ing  Group  22457  (CCL-II). 
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infixr  20  :/: 

data  expr  =  val  real  |  expr  :/;  expr 

eval : :  expr  — >  real 

eval  (val  A)  =  A 

eval  (A  :/;B)  =  (eval  A) /(eval  B) 


Fig.  1.  Monadic  variations  of  the  basic  evaluator 


Our  first  example  of  a  program  written  in  TOy  may  be  seen  in  figure  1.  This  program  is  the  TOy  version 
of  the  evaluator  for  simple  expressions  presented  by  P.  Wadler  in  his  article  [Wad95],  and  will  be  our  starting 
point  m  order  to  compare  monads  and  extensions.  The  evaluator  itself  is  represented  by  function  eval  which 
takes  an  expression  E  as  the  only  input  parameter,  and  returns  the  real  number  resulting  from  evaluating  E 
An  expression  can  be  either  a  real  number  r,  represented  as  val  r  or  a  quotient  between  expressions  ei  and  eo‘ 

In  general,  each  function  f  in  T Oy  is  defined  by  a  set  of  conditional  rules  of  the  form 


f  h  . .  .4  = 


61  ==  e 


1  > 


e-k  == 


where  (ti  forms  a  tuple  of  linear  (i.e.  with  no  repeated  variable)  constructor  terms,  and  e  Ci  e'-  are 

expressions  No  other  conditions  (except  well-typedness)  are  imposed  to  function  definitions.  Rules  have  a 
conditional  reading:  f  t,.  ..t  can  be  reduced  to  e  if  all  the  conditions  m  ==  e'^, . . . ,  e*  ==  ej,  are  satisfied. 
The  condition  part  is  omitted  if  /:  =  0  (as  m  our  previous  example  eval).  The  symbol  ==  stands  for  strict 
equality,  which  is  the  suitable  notion  for  equality  when  non-strict  functions  are  considered.  With  this  notion  a 
condition  e  -=  e’  can  be  read  as:  e  and  e’  can  be  reduced  to  the  same  constructor  term. 

.u-  introduce  non-deterministic  computations  by  different  means,  but  we  only  need  one  of  them  for 

this  discussion,  namely  the  occurrence  of  extra  variables  in  the  right  side  of  the  rules  like  in 

z.list  =  [OjL] 

Although  in  this  case  zJList  reduces  only  to  [0|L] ,  the  free  variable  L  can  be  later  on  instantiated  to  anv  list 
therefore,  any  list  of  integers  is  a  possible  value  of  z_list. 

Computing  in  T Oy  means  solving  goals,  which  take  the  form 


61  ==  e\, 


ek  ==  e' 


pving  as  Its  result  a  substitution  for  the  variables  in  the  goal  making  it  true.  Evaluation  of  expressions  (required 
for  solving  the  conditions)  is  done  by  a  variant  of  lazy  narrowing  based  on  a  sophisticated  strategy,  called  demand 
dnven  strategy  which  uses  the  so-called  definitional  trees  [Ant92]  to  guide  unification  with  patterns  in  left-hand 
sides  of  rules  (see  [LLR93]).  For  instance,  using  the  evaluator  defined  above  we  may  try  the  goal- 


eval  (val  16  ;/:val  4  :/:val  1  :/:val  8)  ==  R 


which  yields  R  ==  0.5. 

As  an  aside,  we  remark  that  the  current  version  of  our  language  does  not  incorporate  lambda  abstractionj 

we  have'ifHllJpTtt  syntactic  facilities  are  usual  in  the  functional  programming  literature,  and 

we  have  included  them  in  some  of  our  examples  in  order  to  fairly  represent  the  monadic  approach.  For  testing 

tern^S'es  [PeySrt  we  have  simply  needed  to  ‘lift’  such  constructions  using  well-known 


3  Funcional-Logic  monads 


evaluator,  following  the  lines  of  Wadler ’s  paper  [Wad95l 
We  also  recall  briefly  some  of  the  basic  concepts  concerned  with  monads,  which  will  be  useful  wLn  comparing 
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monads  and  extensions.  However,  we  will  not  delay  very  much  at  this  point,  assuming  that  the  definition  and 
usefulness  of  monads  are  well-known,  and  referring  to  the  cited  article  for  a  deeper  discussion  of  these  issues. 

To  convert  a  function  B  to  monadic  form  we  change  its  type  to  f::A  ->  m  B,  meaning  that  function  / 

accepts  a  parameter  of  type  A  and  returns  a  value  of  type  B,  with  an  associated  computation  represented  by  m. 
The  structure  of  the  function  will  be  based  on  the  functions  unit::  A  m  A  (also  known  as  result)  and  (*)::m  A 
(A  — ^  m  B)  m  B  (usually  called  bind)  and  indicates  how  the  value  B  is  constructed,  avoiding  any  explicit 

reference  to  the  computation  m.  Only  unit  and  *  (and  perhaps  some  auxiliary  functions)  will  ‘know’  what  m  is 
actually,  and  how  to  deal  with  it.  If  we  want  to  add  some  extra  capabilities  to  the  original  code  of  /  later,  we 
only  need  to  look  for  an  appropriate  data  constructor  m’  that  captures  the  essence  of  the  modification.  Then 
we  redefine  the  type  of  the  function  to  f::A  ->  m’  B,  define  the  new  versions  of  *  and  unit  and,  perhaps,  make 
a  few  local  changes  in  the  code  of  the  function  itself,  but  always  keeping  the  same  basic  structure. 

Figure  2  shows  two ‘classical’ variations  of  the  original  evaluator. 


type  state  =  int 

type  output  =  string 

type  m  A  =  state  — ^  (A, state) 

type  m  A  =  (output, A) 

unit: :  A  — f  m  A 
unit  A  X  =  (A,X) 

unit : ;  A  — >•  m  A 
unit  A  =  ("".A) 

infixr  30  * 

(♦) :  :m  A  — >■  (A  — )•  m  B)  m  B 

(+)  M  K  S  =  let  (A. 32)  =  M  S 
in  K  A  S2 

infixr  30  * 

(*)  :  :ni  A  — y  (A  — ^  m  B)  — ^  m  B 
(X,A)  +  K  =  let  (Y,B)  =  K  A 
in  (X++Y,B) 

tick  :  :  m  () 
tick  X  =  ((),X+1) 

out:: output  -t  m  () 
out  X  =  (X.O) 

eval: :  expr  — >•  m  real 
eval  (val  A)  =  unit  A 

eval  (A  :/:B)  = 

eval  A  *  ARl.  eval  B  *  AR2. 
tick  ♦  A() .  unit  (R1/R2) 

eval: :  expr  — f  m  real 

eval  (val  A)  =  out (line (val  A)  A) 

♦  A()  .unit  A 
eval  (A  :/:B)  = 

eval  A  *  ARl.  eval  B  *  AR2. 
out  (line  (A  :/:B)  (R1/R2)) 

♦  A() .unit  (R1/R2) 

Fig.  2.  Monadic  variations  of  the  basic  evaluator 


The  first  variation,  is  based  on  the  very  useful  state  monad,  taken  from  [Wad95]  and  adapted  to  T Oy  syntax, 
which  is  used  to  count  the  total  number  of  divisions  performed  while  evaluating  the  expression.  The  second 
variation  produces  a  trace  of  the  evaluation.  This  last  variation  uses  a  function  line  which  produces  a  step  of 
the  trace  and  may  be  defined  as; 

line  T  R  =  "eval("  ++showterm  T  ++")<=  "  ++ntunber_to-string  R++"\n" 

assuming  suitable  definitions  for  showterm  and  number _to_string.  The  infix  operator  ++  is  the  standard  function 
for  concatenation  of  lists.  It  can  be  seen  that  the  basic  structure  of  eval  is  kept  almost  unaffected.  If  we  had 
modified  the  initial  code  directly,  this  would  have  been  more  difficult  to  achieve. 


4  FLP  extensions 

In  the  previous  section  we  have  sketched  how  the  monadic  approach  can  be  adopted  in  T Oy.  Now  it  is  time  to 
present  the  alternative  provided  by  our  FLP  extensions. 
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4.1  An  informal  introduction  to  extensions 

The  idea  of  FLP  extensions  is  quite  simple,  and  constitutes  itself  a  good  example  of  mixing  the  resources  of 
logic  and  functional  programming: 

Suppose  we  would  like  to  add  a  new  capability  of  type  C  to  a  given  function  f::A  B.  Then,  all  we  need 
to  do  is  to  extend  the  type  of  the  function  to  f::A  B  C,  meaning  that  the  old  returned  value  is  now  an 
output  parameter,  while  the  new  value  is  introduced  as  the  result  of  the  function. 

Consider  the  initial  basic  evaluator  and  suppose  we  want  to  enrich  the  capabilities  of  the  function 

eval : : expr  real 

by  associating  a  new  value  of  type  C  to  the  currently  returned  real  number.  Then,  we  extend  the  function  with 
the  new  feature,  changing  its  type  to 


eval:: expr  -4  real  -4  C 

Of  course  the  definition  of  eval  also  needs  to  be  modified,  acknowledging  that  the  result  of  the  evaluation  is  no 
longer  the  result  of  the  function,  but  an  output  parameter. 

In  order  to  hide  the  way  the  values  of  type  C  are  composed  we  define  a  combinator 

C  — ^  C  — ^  C 

Hence  the  second  rule  for  eval  will  have  the  shape 

eval  (A  :/:B)  R  =  eval  A  R'l  *  eval  B  R2  ... 

with  the  values  R,  R1 , .  R2  standing  for  the  result  of  the  evaluation  of  A  :/:  B,  A  and  B  respectively.  The  problem 
of  constructing  the  new  result  of  the  function  seems  to  be  solved:  eval  A  R1  and  eval  B  R1  are  actual  values 
of  type  C  related  to  the  ‘old’  values  R1  and  R2,  and  therefore  can  be  combined  by  using  *.  If  later  we  change  C 
by  C’  we  only  need  to  change  the  definition  of  *  but  not  the  basic  structure  of  eval. 

However,  we  still  need  to  associate  the  value  R1/R2  with  the  result  of  the  evaluation  R.  This  will  be  performed 
by  fiinction  iinit,  which  must  ‘identify’  R  and  R1/R2.  In  order  to  generalize  the  definition  to  other  situations, 
both  values  R  and  R1/R2  will  be  input  parameters  of  unit.  The  logical  way  of  adding  unit  to  the  definition  of 
eval  is  simply  by  using  *: 

eval  (A  :/;B)  R  =  eval  A  R1  *  eval  B  R2  *  unit  (R1/R2)  R 

This  means  that  unit  should  return  a  value  of  type  C  and,  since  we  said  above  that  the  result  of  the  functions 
was  already  properly  constructed  by  eval  A  R1  *  eval  B  R2  ,  the  value  of  unit  must  be  a  truly  unit  value 
with  respect  to  the  operation  *.  Therefore  given  a  unit  element  e  of  type  C,  we  can  define  unit  as 

unit : : real  ->  real  C 
unit  A  A  =  e 

where  the  repeated  variable  is  just  a  ‘syntactic  sugar’  of 

unit  A  B  =  e  4=  A==B 

That  is,  unit  returns  e  if  the  strict  equality  A==B  succeeds.'  This  produces  the  desired  identification  between 
the  result  R  and  R1/R2. 


4.2  Extensions  of  the  basic  evaluator 

The  ‘extension  counterpart’  of  the  monadic  variations  presented  in  the  previous  section  may  be  seen  in  figure  3. 
The  type  C  of  our  discussion  is  represented  respectively  by  the  types  trans  and  output,  while  the  unit  elements 
are  id  and  "  ",  where  the  standard  function  id  is  defined  as  usual: 

id  X  =  X 

Further  details  about  these  examples  may  be  found  in  section  5. 
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type  state  =  int  i 

type  trans  =  state  state 

type  output  =  string 

unit : :  k  k  —>  trans 

unit : :  A  — ^  A  output 

unit  A  A  =  id 

unit  A  A  =  "" 

infixr  30  * 

infixr  30  * 

(*) :  :trans  — >■  trans  ^  trans 

(*):: output  -+  output  — >  output 

(♦)  M  K  S  =  K  S2  M  S  ==  S2 

M  *  K  =  M  4+  K 

tick  : :  trans 

out : : output 

tick  =  (1+) 

out  =  id 

eval ; :  expr  real  treins 

eval : :  expr  —¥  real  — output 

eval  (val  A)  E  =  unit  A  R 

eval  (val  A)  R  =  unit  A  R  ♦ 

out  (line  (val  A)  A) 

eval  (A  :/;B)  R  = 

eval  (A  :/:B)  R  = 

eval  A  R1  *  eval  B  R2  ♦ 

eval  A  R1  ♦  eval  B  B2  * 

unit  (R1/R2)  R  *  tick 

unit  (R1  /  R2)  R  * 
out  (line  (A  :/:B)  R) 

Fig.  3.  Extension?  of  the  basic  evaluator 

/ 

4.3  Definition  of  extension 

A  FLP  extension  is  a  tuple  (b,  unit,  *)  where  b  is  an  specific  type,  unit  is  a  function  of  type  A  A  b  and 
definition  unit  A  A  =  e,  e  £  b,  and  where  *  is  a  function  of  type  b  b  b  such  as  (e,  *)  is  a  monoid. 

Now  it  can  be  proved  easily  that  the  variations  of  figure  3  are  actually  extensions.  For  example,  the  pair  ( 
“  ” ,++  )  used  in  the  output  extension  is  known  to  satisfy  the  properties  of  monoids.  The  proof  for  the  other  case 
is  quite  straightforward.  Although  this  definitions  lacks  the  theoretic  background  of  the  definition  of  monad, 
the  structure  of  monoid  is  enough  to  prove  some  simple  assertions  about  the  functions  defined  using  *  and  unit 
in  the  same  line  as  that  of  [Wad95j . 

5  A  comparative  survey 

So  far  we  have  presented  two  ‘classical’  variations  of  the  basic  evaluator,  using  both  extensions  and  monads. 
Now  we  can  present  a  first  comparative  study  of  the  two  techniques.  In  the  following  points  we  show  some  of 
the  advantages  of  using  extensions  that  can  be  checked  directly  in  the  examples. 

•  The  definitions  of  types  for  extensions  are  simpler  than  in  the  case  of  monads.  Indeed,  we  do  not  need  to 
worry  about  how  to  combine  the  old  and  the  new  value,  while  monads  need  to  define  a  suitable  type  constructor 
m.  For  example,  in  order  to  add  the  output  trace  to  the  basic  evaluator,  we  have  defined  the  type 

type  output  =  string 

while  the  monadic  version  needs  also  define 

m  A  =  (A,  output) 

•  As  a  consequence  of  the  previous  point,  functions  unit  and  *  admit  simpler  definitions.  For  instance 

(*) : :  output  — >•  output  ->  output 
M  *  K  =  M  ++K 

indicates  that  the  result  of  combining  two  outputs  is  the  concatenation  of  both  of  them.  Observe,  in  particular, 
the  symmetrical  aspect  of  the  type  of  (*).  This  definition  seems  more  readable  than  the  monadic  variation: 

(*)  : :  m  A  — ^  (A  — ^  in  B)  — ^  in  B 

(X,A)  *  K  =  let  (Y,B)  =  K  A  in  (X++Y,B) 
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•  The  symmetrical  definition  of  *  also  entails  some  practical  consequences,  as  it  allows  the  programmer  to 
change  the  order  of  the  combined  values.  Thus  we  do  not  need  to  end  the  sequence  with  a  unit  expression,  as 
in  the  case  of  monads.  For  instance,  take  the  second  rule  for  eval  in  the  output  monad: 

eval  (A  :/:B)  =  eval  A  *  ARl.  eval  B  * 

AR2.  out  (line  (A  :/:B)  (R1/R2))  * 

A().  unit  (R1/R2) 

It  would  better  to  change  the  order  of  unit  and  out,  writing  instead 

eval  (A  :/:B)  =  eval  A  *  ARl.  eval  B  *  AR2.  unit  (R1/R2) 

*AR.  out  (line  (A  :/:B)  R) 

avoiding  the  unnecessary  repeated  calculation  of  i?l/JR2  and  separating  the  side  effect  from  the  main  computa¬ 
tion,  but  this  is  not  possible  without  changing  the  definition  of  out.  However  the  definition  of  *  for  extensions 
allows  us  to  write 

eval  (A  ;/:B)  R  =  eval  A  R1  *  eval  B  R2  *  unit  (R1/R2)  R 
*  out  (line  (A  :/:B)  R) 

where  R1/R2  is  computed  only  once. 

•  The  separation  between  the  old  and  the  new  values  also  benefits  the  definitions  of  auxiliary  functions  such  as 
tick  or  out.  For  example,  as  tick  must  increase  the  state  we  need  only  write 

tick  =  (1+) 

instead  of  the  monadic  definition 

tick  X  =  ((),X+1) 

These  straightforward  definitions  also  avoid  the  useless  dummy  variables  and  values  ()  that  appear  in  the 
monadic  definitions. 

Of  course,  extensions  have  some  disadvantages  like  any  other  programming  technique.  We  can  point  out  the 
following  drawbacks: 

•  Monads  are  a  more  abstract  technique.  They  are  based  upon  deep  theoretical  results  and  can  be  applied 
to  a  number  of  different  areas  beyond  programming,  such  as  type  inference  or  semantics,  while  extensions  are 
hitherto  just  a  specific  methodology  of  FLP. 

•  Some  monads  cannot  be  thought  of  in  terms  of  extensions,  because  they  are  not  meant  to  add  new  values 
to  a  previously  given  function.  For  instance,  lists  may  be  seen  as  a  monad  (see  [Wad95]),  while  they  cannot  be 
defined  in  terms  of  extensions. 

Therefore,  extensions  cannot  be  applied  to  the  same  situations  as  monads.  And,  can  monads  substitute 
extensions?  In  Section  6  we  will  present  some  applications  of  extensions  that  cannot  be  accomplished  by  monads, 
hence  showing  that  neither  of  both  techniques  may  be  subsumed  into  the  other  one.  ’ 

6  Other  features  of  extensions 

Extensions  and  monads  look  quite  similar,  but  actually  they  can  be  used  to  solve  different  problems.  We  have 
pointed  out  in  Section  5  some  limitations  of  extensions.  Now  we  are  going  to  show  how  extensions  can  be  used 
in  two  situations  where  monads  cannot  be  readily  applied.  ■ 

6.1  Avoiding  unnecessary  computations 

Monads  (as  well  as  extensions  )  allow  one  to  increase  the  capabilities  of  functions  while  keeping  their  basic 
structures^  unaffected..  Of  course,  these  extra  features  also  entail  extra  computation  time.  The  efficiency  of  the 
two  techniques  is  quite  similar  (both  in  time  and  space)  when  the  extra  features  are  computed.  However  the 
situation  chMges  remarkably  in  the  points  of  the  program  where  still  only  the  old  value  of  the  function  is 
required.  This  may  be  specially  extreme  when  dealing  with  the  state  monad  (or  extension). 

Iinagine  for  example  that  we  need  a  variation  of  the  evaluator  of  expressions  that  not  only  computes  the 
resulting  real  number  but  also  maintains  an  ordered  list  with  the  numbers  that  appear  in  the  expression.  Such 
variation  may  be  seen  in  figure  4  using  monads  and  extensions 
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f 

! 

type  state  =  [real] 

type  state  =  [real] 

tick  : :  real  -4  m  0 

tick  : :  real  -4  trans 

tick  A  S  =  (  0 ,  insert  A  S) 

tick  A  =  insert  A 

eval : :  expr  -4  m  real 

eval ; :  expr  — >  real  -4  trans 

eval  (val  A)  =  tick  A  *  AO.unit  A 

eval  (val  A)  R  =  tick  A  ♦  unit  A  R 

eval  (A  :/:  B)  =  eval  A  * 

eval  (A  ;/;  B)  R  =  eval  A  R1  * 

ARl.eval  B  * 

eval  B  R2  ♦ 

AR2.  unit  (R1/R2) 

unit  (R1/R2)  R 

Fig.  4.  Evaluator  yielding  an  ordered  list,  using  monads  (left)  and  extensions  (right) 


with  the  function  insert  defined  as  usual.  Functions  *,  unit  and  types  m  A  and  trans  have  not  been  included 
for  they  are  those  of  the  state  variations  we  showed  before  (figures  2  and  3).  Here  function  tick  is  used  to  insert 
an  element  in  the  ordered  list,  while  the  initial  state  is  the  empty  list.  For  example,  using  extensions  we  may 
try 


which  returns  the  values 


eval  (val  8  :/:val  4  :/:val  2)  R  []  ==  L 


R  ==  4 
L==[2,4,8] 

However,  it  is  possible  that  we  might  still  need  to  evaluate  expressions  just  to  get  the  result,  dismissing  the 
list.  In  this  case,  the  insertion  of  all  the  elements  in  the  list  is  an  unnecessary  overweight  that  should  be  avoided. 
Using  extensions  this  can  be  done  by  simply  not  providing  the  initial  state  []  to  the  goal.  Then  the  result  of 
evaluating  the  expression  is  computed  as  usual,  but  the  state  is  returned  as  a  ’chain  of  actions’  not  evaluated 
yet,  as  is  witnessed  by  the  goal 

eval  (val  8  :/:val  4  :/:val  2)  R  ==  L 

that  returns 


R  ==  4 

L  ==  (insert  8  *  id)  *  ((insert  4  *id)  *  (insert  2  *id)  *id)  *id 
Thus  the  actual  insertion  in  the  list  is  not  carried  out,  and  we  can  define  a  function  eval  ’  as 

eval’  Expr  =  R  <=  eval  Expr  R  ==  _ 

Note  that  this  cannot  be  done  by  using  monads,  because  the  two  values,  the  numeric  result  and  the  list  are 
actually  parts  of  a  single  value.  Effectively,  if  we  do  not  provide  the  initial  state  to  the  monadic  variation,  a 
goal  like 


eval  (val  8  :/:val  4)  ==  L 

yields  an  expression  of  the  shape 

L  ==  (tick  8  *  AO.unit  8)  *  ARl.(tick  4  *  AO.unit  4)  * 

AR2.unit(Rl/R2) 

because  functions  tick,  unit  and  *  cannot  be  reduced  until  a  initial  state  is  provided.  Thus  we  can  either 
compute  both  the  result  and  the  ordered  list,  or  neither. 

The  use  of  the  function  eval  ’  whenever  the  list  is  not  required  can  speed  up  the  program  considerably. 
Checked  with  a  expression  of  300  numbers,  we  have  found  out  that  the  differences  of  time  between  eval’  and 
eval  using  extensions,  can  vary  from  0'38s  to  5' 10s.  And,  despite  the  big  chain  of  insert  and  id  functions  that 
eval’  must  construct,  the  space  required  is  also  less  than  in  the  case  of  actually  performing  the  insertions  with 

eval. 


y 
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6.2  A  parser  for  free 

Consider  the  boolean  expressions  defined  as 

infixr  20  :  /\ : 
inf ixr  15  : \/  ; 

data  expr  =  val  bool  |  expr  :  /\  ;  expr  |  expr  :  \/  :  expr 

Suppose  that  we  decide  to  define  a  evaluator  evalb  for  this  expressions,  returning  not  only  the  result  of  the 
evaluation,  but  also  a  suitable  representation  of  the  expression.  The  code  for  such  function  may  be  seen  in  the 

figure  5,  using  monads  (left  side)  and  using  extensions  (right  side),  and  is  a  simple  application  of  the  output 
feature  presented  before. 


evalb::  expr  m  bool 

evalb  (val  A)  =  out  (conv  A) 

X  unit  A 

evalb  (A  :  \/  :  B)  = 

out  "("  *  AO.  evalb  A  ♦ 
A  Rl.  out  "  or  "  +  A(). 
evalb  B  ♦  AR2.  out  ")"  * 
AO.  unit  (Rl  'or'  R2) 

evalb  (A  :  /\  :  B)  = 

out  "("  *  AO.  evalb  A  * 
A  Rl.  out  "  and  "  *  AO. 
evalb  B  *  AB2.  out  ")"  ♦ 
AO.  unit  (Rl  'and'  R2) 


evalb::  expr  — ^  bool  — >  output 

evalb  (val  A)  R  =  out  (conv  A) 
unit  A  R 

evalb  (A  :  \/  :  B)  R  = 

out  "("  *  evalb  A  Rl  * 
out  "  or  "  * 
eva,lb  B  R2  * 
unit  (Rl  'or'  R2)  R  *  out  ")" 

evalb  (A  :  /\  ;  B)  R  = 

out  "("  ♦  evalb  A  Rl  + 
out  "  and  "  * 
evalb  B  R2  * 

unit  (Rl  'and'  R2)  R  ♦  out  ") 


Fig.  5.  Boolean  evaluator  with  output,  using  monads  and  extensions 


Functions  or  and  and  are  defined  as  usual  in  functional 
defined  as 


programming,  while  function  conv  may  be  easily 


conv  true  =  "T" 
conv  false  =  "F" 

For  example,  using  the  monadic  variation,  we  may  try 

evalb  (val  true  :  /\  :  (val  false  :  \/  :  val  true))  ==  R 

which  returns 


R  ==  (  "(T  and  (F  or  T))"  ,  true  ) 

we  decide  that  representations 

iiKe  (land  (F  or  T))  are  definitely  nicer  and  more  readable  than 

evalb  (val  true  ; /\  ;  (val  false  ;  \/ :  val  true)) 

evalb  Expr  R  ==  "(F  and  (F  or  T))" 
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which  succeeds  with 

Expr  ==  val  false  :  /\  :  (val  false  :  \/  :  val  true) 

R  ==  false 

This  nice  outcome  of  extensions  is  an  example  of  the  generate  &  test  techniques,  very  usual  in  logic  programming. 
Therefore,  ours  is  actually  a  recursive  top-down  parser  of  the  grammar  rules  expressed  in  evalb  by  means  of 
output  (for  terminals)  and  recursive  calls  of  evalb  (for  non-terminals). 

But,  why  is  it  not  possible  to  use  the  monadic  variation  in  this  case?  It  is  due  to  the  combination  of  the 
string  representation  and  the  output  value,  which  is  a  free  variable.  For  example,  the  goal 

evalb  Expr  ==  ("(F  and  T)",R) 

loops.  We  must  recall  that  strict  equality  does  a  ‘careful  matching’  as  we  showed  before.  In  the  example,  this 
means  generating  the  outer  constructor  of  both  "  (F  and  T)  "  and  R  by  means  of  evalb  Expr.  But  getting  an 
outer  constructor  for  R  entails  generating  a  whole  expression,  and  by  using  the  second  rule  of  evalb,  infinite 
expressions  may  be  generated.  These  expressions,  all  of  which  have  an  or  in  their  representations,  when  finally 
compared  with  (F  and  T) ,  fail. 

7  Conclusions 

We  have  shown  throughout  this  paper  that  extensions  are  a  suitable  mechanism  to  solve  a  number  of  problems 
when  working  in  a  functional-logic  language.  Although  lacking  the  deep  theoretical  background  of  monads, 
extensions  can  be  used  as  an  alternative  to  define  easily  reusable  code.  The  concepts  used  are  simple,  and  were 
already  known  in  each  declarative  paradigm,  such  as  the  use  of  arguments  in  logic  programming  to  return 
output  values,  or  the  definition  of  higher  order  combinators  (e.g.  *)  in  order  to  connect  different  computations 
in  sequence.  The  novelty  of  our  approach  is  that  it  combines  techhiques  of  both  main  declarative  streams, 
yielding  a  new  mechanism  that  allows  us  to  address  problems,  as  the  addition  of  new  features  to  functions,  in 
a  simple  and  appealing  way.  Specifically,  extensions  avoid  the  necessity  of  lambda  abstractions,  provide  a  more 
symmetric  definition  of  the  combinator  *  -  from  the  point  of  view  of  types  -  and  lead  to  nicer  and  mote  natural 
definitions  of  types  and  auxiliary  functions. 

In  spite  of  all  the  resemblances,  extensions  and  monads  are  different  techniques,  each  one  with  its  own 
particularities  and  limitations.  An  advantage  of  extensions  is  that  they  provide  functions  with  the  possibility 
of  multiple  modes  of  use,  therefore  defining  functions  that  can  be  reused  in  a  wider  sense  than  in  the  case  of 
monads.  Another  advantage  is  that  the  state  extension  allows  one  to  dismiss  the  stateful  computations  whenever 
they  are  not  interesting,  hence  saving  both  time  and  space. 
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Abstract.  The  traditional  representation  of  a  program  as  a  linear  sequence  of  text  forces  a  particular  style  of  program 
construction  and  development.  Tools  such  as  editors,  compilers,  linkers  and  file  managers  are  required  to  translate 
and  execute  these  linear  sequences  of  text.  At  some  stage  in  the  execution  sequence  the  source  text  is  checked  for 
type  correctness  and  its  translated  form  is  linked  to  values  in  the  environment.  When  this,  and  any  other  form  of 
program  checking,  is  performed  early  in  the  execution  process  confidence  in  the  correctness  of  the  program  is  raised 
During  program  exeeution,  other  tools  such  as  symbolic  debuggers  and  run-time  browsers  are  used  to  inspect  the 
running  state  of  programs.  Relating  this  run-time  state  to  the  linear  text  is  often  problematical. 

Within  our  research  into  persistent  systems  we  have  developed  a  technique  that  allows  the  persistent  environment  to 
participate  in  the  program  construction  and  development  process.  The  technique  allows  the  representations  of  source 
programs  to  include  direct  links  (hyper-links)  to  values,  including  code,  that  already  exist  in  the  environment.  By 
analogy  with  hyper-text,  where  a  piece  of  text  contains  hyper-links  to  other  pieces  of  text,  this  source  representation 
is  called  a  hyper-program. 

Hyper-programming  achieves  our  two  objectives  of  being  able  to  link  earlier  than  before,  at  program  composition 
time,  and  through  the  use  of  hyper-Hnks  to  values  in  the  environment  to  represent  sharing  and  thus  closure  and 
through  this  the  run-time  state  of  a  program.  This  paper  reviews  our  work  on  hyper-programming,  discusses  the 
advantages  of  the  technique  and  proposes  some  current  research  areas.  These  include  presenting  a  single 
representation  of  data  and  code  throughout  the  software  process;  adapting  hyper-programming  to  persistent  contexts 
that  do  not  enforce  referential  integrity,  such  as  the  WWW;  and  implementing  and  using  hyper-programming  in 
standardised  languages  and  inter-operability  mechanisms. 

1  Introduction 

Figure  1,  taken  from  IMCC+95],  shows  an  example  of  a  Napier88  hyper-program.  The  program  source,  which  is 
itself  a  persistent  object,  comprises  text  and  hyper-links  to  other  objects  in  the  persistent  store. 

The  first  hyper-link  is  to  a  persistent  first-class  procedure  value  writeString  which  writes  a  prompt  to  the  user.  The 
program  then  calls  another  procedure  readString  to  read  in  a  name,  and  then  finds  an  address  corresponding  to  that 
name.  This  is  done  by  calling  a  procedure  lookup  to  find  the  address  in  a  table  data  structure  linked  into  the  hyper¬ 
program.  The  address  is  then  written  out.  Note  that  the  code  objects  {readString,  writeString  and  lookup)  are  denoted 
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using  exactly  the  same  mechanism  as  data  objects  (the  table)'  and  all  of  these  are  external  to  the  hyper-program  but 
within  the  persistent  environment. 

persistent  store 


A  requirement  for  hyper-programming  is  the  presence  of  an  external  value  space  to  which  bindings  can  be 
constructed  during  program  composition.  The  external  source  may  be  provided  by  a  persistent  store,  a  file  system  or 
any  other  mechanism  such  as  the  WWW .  No  matter  which  external  source  is  used,  a  fundamental  change  in  the  nature 
of  the  source  program  has  taken  place  since  it  now  contains  both  text  and  hyper-links  to  values  in  the  environment.  This 
non-flat  representation  of  the  program  source  challenges  our  traditional  notions  of  what  constitutes  a  computer  program. 
The  reason  for  the  name  hyper-program  is  the  analogy  with  hyper-text  which  is  also  non-flat  and  contains  both  text  and 
hyper-links  to  other  hyper-text. 

The  major  issue  in  building  hyper-programming  systems  concerns  the  semantics  of  the  hyper-links,  such  as: 

•  what  can  a  hyper-link  refer  to? 

•  what  guarantees  can  be  made  about  a  hyper-link’s  referent  data? 

•  how  are  hyper-links  typed  and  when  does  type-checking  occur? 

The  degrees  of  fi-eedom  regarding  what  a  hyper-link  can  refer  to  depend  upon  the  programming  language 
semantics  and  the  measure  of  openness  is  the  system.  Normally  hyper-links  will  be  able  to  refer  to  all  language  first 
class  values  values.  Second  class  entities,  not  in  the  value  space  such  as  types,  may  also  be  conveniently  hyper-linked 
depending  on  the  flavour  of  the  language.  Update  may  be  accommodated  through  hyper-links  by  linking  to  locations 
which  may  or  may  not  be  first  class  values.  More  interesting  is  the  extent  to  which  hyper-links  may  refer  to  values 
created  independently  of  the  system,  such  as  Web  pages  and  DCOM  objects.  Furthermore  the  open-ness  of  the  system 
can  be  extended  by  making  the  hyper-program  representation  open  for  other  tools  to  manipulate. 

Referential  inte^ty  in  a  hyper-programming  system  means  that  once  a  hyper-link  is  established  it  is  guaranteed  by 
the  system  to  exist  aiid  to  be  the  same  value  when  the  hyper-link  is  executed.  While  this  guarantee  may  be  provided  by 
a  sfrongly  typed  persistent  object  store,  it  may  also  be  expensive  to  provide  in  a  distributed  system.  Variations  therefore 
mclude  the  hyper-link  being  valid  but  not  necessarily  referring  to  the  original  value,  and  the  hyper-link  referring  to  a 
copy  of  the  original.  This  may  only  be  a  problem  where  object  identity  is  important  such  as  in  sharing  semantics.  A 
hyper-program  may  therefore  display  a  range  of  failure  modes  from  not  failing  to  failure  fiom  the  hyper-link  being  no 
longer  valid.  ° 

The  final  issue  is  how  hyper-links  are  typed,  if  at  all.  We  will  assume  that  for  the  present  that  they  are.  The 
interesting  aspect  of  type  checking  is  that  the  contract  between  the  program  and  the  referenced  value  may  now  take  on  a 
different  agreement  procedure.  Instead  of  the  program  asserting  the  type  of  the  hyper-link  and  the  type  checking  system 
ensurmg  that  the  hyper-Imk  has  the  correct  type  when  it  is  used,  the  reverse  may  be  used.  That  is  the  hyper-link  knows 
Its  own  type  and  therefore  when  it  is  used  the  program  can  be  made  to  cpnfonn  to  this  type.  Statically  this  removes  the 
need  for  type  specifications  for  hyper-links  in  hyper-programs  and  dynamically  it  means  that  the  program  may  be  in 
error  rather  than  the  hyper-link.  .  ^ 


‘  Note  also  that  the  names  used  in  this  description  of  the  hyper-links  have  been 
semantics  of  the  hyper-program. 


associated  with  the  objects  for  clarity  only,  and  are  not  part  of  the 
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This  paper  reviews  our  work  on  hyper-programming,  discusses  the  advantages  of  the  technique  and  proposes  some 
current  research  areas.  These  include  presenting  a  single  representation  of  data  and  code  throughout  the  software 
process;  adapting  hyper-programming  to  persistent  contexts  that  do  not  enforce  referential  integrity,  such  as  the  WWW; 
and  implementing  and  using  hyper-programming  in  standardised  languages  and  inter-operability  mechanisms. 

2  Motivations  &  Previous  Work 

Our  work  on  hyper-programming  is  motivated  by  a  belief  that  programming  language  systems  could  provide  better 
support  for  the  software  engineering  process  than  they  do  at  present.  In  particular,  consider  the  traditional  compose- 
cycle  of  program  development  as  illustrated  in  Figure  2. 


Figure  2.  The  Traditional  Compose-Compile-Link-Execute  Cycle 

In  precis,  a  program  is  composed  using  a  text-editor;  compiled  using  a  compiler,  which  may  also  link  in  other 
source  text;  linked  with  other  pre-compiled  code;  and  finally  executed  where  it  may  link  to  persistent  data  such  as  files. 
During  execution,  other  tools  such  as  symbolic  debuggers  and  run-time  browsers  may  be  used  to  inspect  the  running 
state  of  the  program.  Thus  there  are  four  main  processes:  composition,  compilation,  linking  and  execution  each  with 
their  appropriate  tools  such  as  text-editors,  compilers,  linkers,  debuggers  and  browsers.  Each  tool  operates  on  a 
particular  translated  version  of  the  program  such  as  source  text,  object  code  or  executable  code. 

There  are  two  obvious  questions  that  may  be  asked  about  the  compose-compile-link-execute  cycle.  They  are; 

•  why  are  there  so  many  processes  and  translated  forms  of  the  program?  and 

•  what  level  of  detail  should  the  user  see? 

For  the  systems  programmer  the  processes  and  translated  forms  provide  the  necessary  level  of  control  over  the 
cycle.  The  translated  forms  allow  common  tools,  such  as  optimisers,  to  be  used  even  where  the  original  forms  are  from 
disparate  sources.  The  processes  are  necessary  for  manipulating  the  translated  forms. 

From  the  applications  programmer’s  point  of  view,  the  processes  and  translated  forms  often  constitute  noise  in  the 
execution  cycle  and  a  distraction  from  the  task  of  constructing  the  system.  Modem  programming  environments,  such  as 
CodeWarrior  [Met99],  attempt  to  hide  this  level  of  detail  from  the  applications  programmer.  Hyper-programming  is  a- 
further  step  in  this  direction  and  the  paper  explores  how  effective  the  concept  can  be  in  different  environments. 

2.1  Constructing  Hyper-programs 

The  primary  motivation  for  hyper-programming  is  to  allow  the  user  to  compose  programs  interactively  [FDK+92, 
KCC-t-92],  navigating  the  environment  and  selecting  data  items,  including  code,  to  be  incorporated  into  the  programs. 
This  removes  the  need  to  write  access  specifications  for  extant  data  items  that  are  used  by  a  program.  For  example,  in  a 
file  system  it  may  be  a  path  name,  and  in  a  persistent  object  store  it  may  be  a  path  to  an  object  from  a  root  of 
persistence. 

Our  first  attempts  at  constructing  a  hyper-programming  system  were  conducted  in  the  Napier88  persistent 
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programming  environment.  The  strongly  typed  persistent  object  store  guaranteed  referential  integrity  of  the  hyper-links. 
Existing  languages  that  allow  a  program  to  link  to  persistent  data  items,  including  files,  at  any  time  during  its  execution 
require  it  to  contain  code  to  specify  the  access  path  and  type  for  each  data  item.  The  access  path  defines  how  the  data  is 
found  by  following  a  particular  route  through  the  persistent  store  starting  from  a  root  of  persistence.  The  type  specifies 
the  expected  type  of  the  data  at  that  position.  When  a  program  is  compiled  the  compiler  checks  that  subsequent  use  of 
the  data  is  compatible  with  this  expected  type.  When  the  program  is  executed  the  run-time  system  checks  that  the  data  is 
present  at  the  declared  position  and  that  it  does  have  the  expected  type. 

This  mechanism  gives  flexibility  because  a  program  can  link  to  data  in  the  store  at  any  time  during  its  execution. 
However  in  many  cases  the  programmer  knows  that  a  particular  data  item  is  present  in  the  store  at  the  time  the  program 
is  written  and  the  programming  system  could  obtain  all  the  information  in  the  access  specification  by  inspecting  the 
data  item  at  that  time. 

In  a  hyper-programming  system  the  programmer  has  the  option  of  linking  existing  data  items  into  a  program  by 
pointing  to  graphical  representations  rather  than  writing  access  specifications.  There  are  two  advantages  to  this  early 
composition-time  linking.  Firstly,  errors  that  may  occur  in  programs  due  to  the  access  specification  being  invalid  at  the 
time  of  execution  are  completely  avoided.  This  may  occur  where  the  store  topology  has  changed  and  the  access  path  no 
longer  exists,  even  if  the  object  does;  where  the  object  has  been  deleted;  or  where  the  object  has  been  replaced  by  one  of 
a  different  type.  In  all  cases  the  contract  between  the  program  and  the  persistent  store  has  been  broken  and  the  program 
may  not  execute  safely. 

In  the  hyper-programming  system  the  hyper-link  is  direct  to  the  object  and  is  guaranteed  to  be  valid,  at  the  time  of 
the  program  execution,  by  the  persistent  store’s  referential  integrity.  Thus  if  the  topology  of  the  store  changes,  the  link 
will  still  be  valid;  the  object  may  not  be  deleted  since  the  hyper-program  still  has  access  to  it;  and  it  may  not  change  its 
type. 

Figure  3  shows  an  example  of  the  user  interface  that  might  be  presented  to  the  user  by  a  hyper-program 
editing/browsing  tool.  The  editor  window  (top-left)  contains  embedded  buttons  representing  hyper-program  links;  when 
a  button  is  pressed  the  corresponding  object  is  displayed  in  a  browser  window  (lower  region). 
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Figure  3.  User  Interface  to  a  Hyper-Program  Editor 


The  hyper-links  to  persistent  values  are  placed  in  the  hyper-program  by  selecting  each  value  with  the  store 
browsing  tool  and  then  pressing  the  Link  button.  In  Napier88,  the  system  asks  the  programmer  whether  to  link  the 
program  to  the  value  itself  or  to  the  store  location  that  currently  contains  the  value.  The  editor  then  inserts  the  link  at  the 
current  text  position,  represented  by  a  light-button. 
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2.2  Safety  and  Efficiency  / 

Hyper-programming  can  provide  improved  safety  in  several  ways.  One  of  these  is  that  it  allows  some  program 
checks  to  be  performed  earlier  than  normal,  subsequently  giving  increased  assurance  of  program  correctness.  This  is 
possible  because  data  items  accessed  by  a  program  may  be  available  for  checking  before  ruri-time.  Referential  integrity 
then  ensures  that  the  checked  data  remains  available  at  run-time. 

Checking  can  be  performed  at  several  stages  in  the  program  development  process  in  existing  systems.  The 
principal  opportunities  are  at  compilation-time  when  a  program  is  translated  into  an  executable  program,  and  at  run¬ 
time  when  the  executable  progi'am  is  executed.  Categories  of  checking  include  checking  programs  for  syntactic 
correctness  and  type  consistency,  and  checking  persistent  data  access. 

2.2.1  Checking  Persistent  Data  Access 

In  conventional  strongly  typed  persistent  systems  a  program  contains  an  access  specification  for  each  persistent 
data  item  used.  These  access  specifications  are  checked  at  run-time:  at  that  time  the  system  verifies  that  each  data  item 
is  present  in  the  store,  with  the  previously  declared  access  path  and  type. 

A  program  execution  will  fail  if  the  store  does  not  contain  a  route  to  a  data  item  corresponding  to  the  access  path 
specified  in  the  program.  Thus  even  if  it  is  known  at  the  time  of  writing  that  a  particular  program  will  execute  correctly, 
it  cannot  be  predicted  when  it  may  fail  on  some  future  execution. 

The  use  of  hyper-programs  as  source  representations  allows  the  checking  of  access  specifications  to  be  performed 
before  run-time.  Each  link  in  a  hyper-program  denotes  a  data  item  that  exists  in  the  store  at  the  time  the  hyper-program 
is  composed.  The  process  of  checking  the  access  path  is  moved  from  run-time  to  program  composition  time.  The  access 
path  is  established  incrementally  as  the  programmer  manipulates  the  graphical  representations  of  the  data  in  the  store  to 
locate  the  required  data  item.  Once  the  path  has  been  established  the  data  item  at  the  end  of  it  is  linked  into  the  hyper¬ 
program  and  the  path  need  not  be  followed  again  at  execution  time.  The  hyper-program  will  be  unaffected  if  the  access 
path  is  then  removed.  " 

The  access  path  part  of  the  access  specification  is  established  during  hyper-program  composition.  The  other  part, 
the  type  specification  of  the  data  item,  is  checked  when  the  type  consistency  of  the  hyper-program  is  verified  at  or 
before  compilation-time.  The  system  checks  that  the  type  of  the  data  item  denoted  by  the  link  is  compatible  with  the  use 
of  the  link  in  the  program. 

Creating  direct  links  from  a  hyper-program  to  values  in  the  store,  with  the  attendant  safety  benefits  described 
above,  is  only  applicable  where  values  are  present  in  the  store  at  hyper-program  composition  time.  Added  flexibility  can 
be  gained  by  using  links  to  denote  mutable  locations  in  the  store.  Linking  a  location  into  a  hyper-program  involves  the 
same  processes  as  for  linking  a  value,  with  the  difference  that  the  value  associated  with  the  link  changes  when  the 
location  is  updated.  Updates  to  the  location  may  occur  at  any  time  after  the  composition  of  the  hyper-program.  Strong 
typing  ensures  that  the  type  of  any  value  assigned  to  a  location  is  compatible  with  the  type  of  its  original  contents.  This 
allows  the  type  checking  of  persistent  locations  to  be  performed  at  compilation-time.  The  values  in  locations  associated 
with  the  links  in  a  hyper-program  can  vaty  but  their  types  will  always  remain  compatible.  Where  a  link  denotes  a 
location,  that  location  is  linked  directly  into  the  executable  program  produced  from  the  hyper-program,  so  that  updates 
to  the  location  also  affect  the  executable  program. 

2.3  Experience 

The  benefits  of  hyper-programming  described  in  [FDK+92,  KCC+92,  MCC+95]  may  be  summarised  as: 

•  being  able  to  perform  program  checking  early 

•  support  for  source  representations  of  all  object  closures 

•  being  able  to  enforce  associations  from  executable  programs  to  source  programs 

•  availability  of  an  increased  range  of  linking  times 

•  increased  program  succinctness 

•  increased  ease  of  program  composition 

3  Current  Work 


3.1  Options  for  Further  Development 

Hyper-programming  as  described  in  the  previous  section  is  implemented  in  NapierSS  [MBC+96]  and  using  a 
persistent  form  of  Java,  PJama  [ADJ+96].  Both  implementations  are  based  on  the  use  of  a  closed-world,  single¬ 
language,  programming  environment.  The  principle  advantage  of  this  is  the  degree  of  control  that  can  be  exercised  over 
the  data  and  code  within  the  environment.  In  particular,  a  type  system  can  be  enforced  over  the  entire  lifetime  of  the 
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data  and  code,  and  referential  integrity  can  be  guaranteed  by  the  environment  implementation.  Thus,  once  established,  a 
reference  between  two  components  will  never  become  accidentally  invalid. 

The  use  of  such  m  environment  offers  various  benefits,  as  discussed  previously,  at  the  cost  of  limiting  flexibility. 
There  are  thus  two  main  avenues  for  further  development  of  the  hyper-programming  concept; 

•  to  further  pursue  the  benefits  of  using  a  closed-world  system,  accepting  the  limitations  that  this  implies;  and 

•  to  investigate  how  far  the  closed-world  restrictions  may  be  relaxed  to  increase  flexibility,  while  retaining  at  least 
some  of  the  original  benefits  of  hyper-programming. 

Sections  3.2  to  3.4  describe  three  areas  of  research  based  on  a  closed-world  platform;  hyper-code,  in  which  a  single 
uniform  representation  of  code  and  data  is  presented  throughout  the  programming  life-cycle;  support  for  application 
evolution  based  on  tracking  relationships  between  system  components  using  referential  integrity;  and  statically 
checkable  dependant  types.  Some  other  areas  in  which  a  closed-world  could  be  exploited,  although  not  discussed 
further  here,  include; 

•  version  control,  configuration  management  and  documentation  systems  [MCC+95];  and 

•  debugging,  profiling  and  optimisation  [CCK-t-94b]. 

Sections  3.5  and  3.6  examine  two  ways  in  which  the  hyper-program  platform  constraints  may  be  usefully  relaxed; 
constructing  programs  over  an  unreliable  network  such  as  the  World  Wide  Web;  and  hyper-programming  using 
commercially  significant  languages  and  inter-operability  standards,  such  as  C++  [Str86],  CORBA  rOMG981  DCOM 
[Mic96]  etc. 

3.2  Hyper-Code 

One  of  the  original  motivations  for  persistent  programming  was  to  remove  the  conceptually  unnecessary 
distinction  between  short-term  and  long-term  data  [ABC+83].  This  was  followed  by  the  recognition  that  code  and  data 
can  usefully  be  treated  in  a  uniform  way  [AM85].  Hyper-programming  itself  involved  a  further  unifying  step  in  which 
source  programs  themselves  became  persistent  data,  along  with  the  compilers,  editors  and  other  tools  with  which  they 
were  manipulated  [KCC+92].  There  has  thus  been  a  progression  of  attempts  to  encompass  ever  more  of  the  disparate 
entities  that  comprise  a  Persistent  Application  System  (PAS)  within  a  unified  framework. 

Visual  interaction  with  persistent  data,  such  as  that  provided  by  generic  object  browsing  systems  [BOP+89,  Coo90, 
pB88,  GR83,  KD90,  OHK87,  ZDK+99],  has  proved  to  be  a  convenient  and  natural  way  for  database  users  to  address 
informal  queries  over  the  contents  of  a  database.  The  users  of  such  tools  can  browse  freely  around  the  data  structures 
and  values  of  a  datable,  avoiding  the  necessity  to  write  down  algebraic  expressions  to  perform  the  equivalent  accesses. 
Where  appropriate  it  is  also  possible  to  perform  updates  or  invoke  more  complex  methods  over  the  objects  depicted  on 
the  screen.  Such  tools  are  patly  preferred  to  a  traditional  queiy-based  approach  for  simple  queries  and  updates  to 
persistent  data  such  as  held  in  object-oriented  databases. 

The  advantages  of  this  style  of  access  are  comparable  to  the  advantages  of  a  modem  iconic  operating  system 
interface  over  a  traditional  command-line  based  approach.  In  addition,  however,  a  more  general  programming  algebra  is 
required  so  that  more  complex  and  longer-mnning  queries  may  be  handled.  This  rather  fiaistratingly  gives  rise  to  two 
quite  separate  mechanisms  for  manipulating  the  same  values  within  a  system,  with  the  choice  of  mechanism  being 
somewhat  arbitrary  for  tasks  in  the  middle  ground  between  trivial  and  complex. 

Current  work  on  hyper-code  aims  to  complete  the  progressive  integration  of  PAS  entities  [CCK-l-94c],  by 
presenting  the  programmer  with  a  single  representation  form  for  all  code  and  data  throughout  all  stages  of  the 
programming  process.  These  stages  include  at  least  object  store  browsing,  program  construction,  execution,  debugging 
and  maintenance.  The  single  representation  form  is  based  on  source  code,  the  argument  being  that  all  other  forms  of 
code  and  data  are  used  for  pragmatic  implementation-driven  reasons,  rather  than  being  conceptually  necessary.  Since 
the  representation  must  be  able  to  accommodate  closures,  by  necessity  it  is  a  hyper-program  form  that  can  include  direct 
links. 

Hyper-code  provides  the  basis  for  a  new  style  of  editor  that  includes  three  unifying  concepts,  the  combination  of 
which  makes  the  editor  the  only  mechanism  that  is  required  for  interaction  with  the  database  system.  The  three 
important  unifying  concepts  are;  , 

1.  Data  of  any  type  supported  by  the  system  may  be  browsed  and  edited  in  a  uniform  manner.  This  includes  a 

uniform  treatment  of  procedure  closures;  a  drawback  of  previous  browsers  is  that  they  could  not  adequately 
handle  procedures.  ^ 

2.  Source  code  is  treated  not  as  a  fundamental  building  block  within  the  programming  system,  but  instead  as  a 
transient  text-based  view  of  a  value.  The  source  does  not  have  a  conceptual  permanent  existence  within  the 

system,  but  is  apparently  generated  from  any  value  that  may  be  browsed. 

3.  As  a  further  consequence  of  the  generic  treatment  of  procedure  values  and  source  code,  the  artificial  distinction 
between  source  and  executable  values  within  a  running  system  is  completely  removed. 

The  major  difference  between  this  and  other  browsers  is  therefore  in  the  uniform  treatment  of  the  executable  and 
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source  code  forms  of  procedures,  and  hence  programs.  Furthermore,  the  manipulation  of  code  made  possible  by  the 
unification  strategy  is  sufficiently  general  to  subsume  the  usual  process  of  program  editing,  compilation  and  linking 
which  is  normally  associated  with  the  manipulation  of  code  bodies  within  a  system.  In  constructing  a  program,  the 
programmer  writes  hyper-code.  During  execution,  during  debugging,  When  a  run  time  error  occurs  or  when  browsing 
existing  programs,  the  programmer  is  presented  with,  and  only  sees,  the  hyper-code  representation.  Thus  the 
programmer  need  never  know  about  those  entities  that  the  system  may  support  for  reasons  of  efficiency,  such  as  object 
code,  executable  code,  compilers  and  linkers.  These  are  maintained  and  used  by  the  underlying  system  but  are  merely 
artifacts  of  how  the  program  is  stored  and  executed,  and  as  such  are  completely  hidden  from  the  programmer. 

A  consequence  of  the  above  is  that  the  hyper-code  editor  is  the  only  interfacing  tool  required  to  perform  queries  of 
any  complexity  against  the  database,  or  to  introduce  new  data  and  program  to  it.  The  programmer  may  thus  concentrate 
on  the  inherent  complexity  of  the  application  rather  than  on  that  of  the  support  system. 

3.2.1  Hyper-Code  Operations 

The  previous  hyper-programming  implementations  in  Napier88  [Kir92]  and  Java  [ZDK+99]  approach  this  ideal, 
but  fall  short  in  two  ways.  Firstly,  the  programmer  is  aware  of  a  distinction  between  the  source  and  compiled  versions 
of  code  entities;  and  secondly,  code  and  data  entities  are  manipulated  differently,  using  an  editor  and  an  object  browser 
respectively.  Hyper-code  removes  these  distinctions.  In  the  first  case,  the  occurrence  of  system  activities  such  as 
compilation  and  linking  is  hidden,  since  they  are  implementation  details-— the  view  presented  to  the  programmer  is  one 
of  source  level  interpretation.  In  the  second  case,  all  interaction  with  the  hyper-code  system  is  via  a  single  hyper-code 
editor  that  fulfils  the  functions  of  both  the  browser  and  editor  in  the  previous  systems.  The  hyper-code  editor  supports 
only  the  following  operations: 

•  evaluate;  this  executes  a  selected  fragment  of  hyper-code  and  returns  the  result,  if  any,  as  a  new  hyper-code 
fragment; 

•  explode;  this  expands  a  selected  link  in  a  hyper-code  fragment  to  show  more  detail,  which  is  itself  expressed  in 
the  form  of  hyper-code; 

•  unexplode;  this  contracts  an  exploded  link  back  to  its  original  form; 

•  edit;  this  includes  all  conventional  editing  facilities; 

•  get  root:  this  returns  a  selected  persistent  root,  as  a  hyper-code  fragment. 

A^en  composed,  these  operations  are  sufficient  to  support  all  program  construction,  execution  and  persistent 
object  browsing  activities.  Note  that  various  system  activities  are  implicit  in  the  operations.  For  example,  the 
implementation  of  the  evaluate  operation  involves  syntax  checking,  compilation  and  invocation  of  the  selected  code 
representation. 

The  semantics  of  the  hyper-code  operations  can  be  defined  in  terms  of  four  abstract  operations,  which  are  reflect, 
reify,  execute  and  transform.  As  shown  in  Figure  4,  these  operate  on  two  distinct  domains:  the  domain  of  persistent 
hyper-code  entities  and  the  domain  of  hyper-code  representations.  The  former  domain  contains  all  of  the  first  class 
values  defined  by  the  programming  language,  together  with  various  non-first-class  entities  for  which  it  may  be  useful  to 
have  representations,  such  as  types,  classes  and  executable  code.  Only  the  latter  domain,  that  of  hyper-code 
representations,  is  made  explicit  to  the  programmer. 


Hyper-Code  Entities  Domain  Hyper-Code  Representations  Domain 


The  reflect  and  reify  abstract  operations  simply  map  between  the  hyper-code  entities  and  their  representations. 
The  execute  operation  takes  place  within  the  hyper-code  entities  domain;  it  involves  the  execution  of  an  executable 
entity,  potentially  with  side-effects  on  the  domain.  Correspondingly,  the  transform  operation  takes  place  within  the 
representation  domain,  involving  the  manipulation  of  hyper-code  representations.  The  hyper-code  operations  can  be 
understood  in  terms  of  the  abstract  operations  as  follows: 

•  evaluate  first  reflects  a  hyper-code  representation  to  a  corresponding  hyper-code  entity.  If  that  entity  is 


executable  it  is  executed.  If  the  execution  produces  a  result  entity,  or  if  the  original  entity  is  non-executable,  that 
entity  is  reified  to  produce  a  result  representation. 

•  explode  and  unexplode  both  reflect  a  hyper-code  representation  to  a  corresponding  hyper-code  entity,  and  then 
reify  that  entity  to  produce  a  more  or  less  detailed  result  representation,  respectively. 

•  edit  involves  transformation  of  an  existing  or  null  hyper-code  representation  into  a  new  representation. 

•  get  root  involves  reification  of  a  hyper-code  entity  to  produce  a  representation. 

It  should  be  stressed  that  the  abstract  operations  are  purely  definitional:  only  the  hyper-code  representations 
domain  and  the  hyper-code  operations  are  visible  to  the  programmer. 

3.2.2  Hyper-Code  Representations 

The  operations  and  domains  described  in  the  previous  section  may  be  applied  to  an  implementation  of  hyper-code 
in  any  suitable  language.  The  precise  form  of  the  hyper-code  representation  (HCR)  will  vaiy  depending  on  the  syntax  of 
the  chosen  language,  but  will  be  guided  by  the  following  criteria  that  will  apply  for  all  languages: 

•  The  HCR  must  accommodate  new  programs  written  in  the  normal  way.  This  implies  that  the  representation  must 
include  pure  text  as  a  special  case. 

•  The  HCR  must  support  hyper-program  links,  for  the  reasons  already  discussed. 

•  The  HCR  must  support  detailed  views  of  linked  entities,  to  arbitrary  levels  of  detail,  in  order  that  the  hyper-code 
editor  may  subsume  the  functions  of  an  object  browser. 

•  Since  there  must  only  be  a  single  HCR,  the  detailed  views  of  entities  must  themselves  comprise  text  and  hyper¬ 
program  links  in  the  same  form  as  could  be  constructed  by  the  programmer. 

•  Furthermore,  the  detailed  views  should  be  self-contained  and  syntactically  valid.  Thus,  for  any  detailed  view  of 
an  entity,  it  should  be  possible  to  copy  its  representation,  paste  this  into  a  new  window,  and  evaluate  it  without 
error.  The  result  of  this  evaluation  will  depend  on  the  semantics  of  the  language. 

Currently  we  have  designed  HCR  forms  for  PJama  and  ProcessBase^,  and  we  are  in  the  process  of  implementing 
them.  Figure  5  shows  an  example  in  ProcessBase,  in  which  unexploded  links  to  values  are  denoted  by  rounded  white 
rectangles,  and  unexploded  links  to  types  by  rounded  black  rectangles.  Exploded  links  are  denoted  by  shaded 
rectangles,  with  the  internal  details  depending  on  the  particular  entity.  The  example  shows  the  definition  of  a  procedure 
newPerson,  which  takes  a  name  and  an  age  as  parameters,  and  returns  a  view  (record)  containing  them  and  a  unique  id 
number.  The  id  is  obtained  by  calling  another  procedure  to  increment  a  shared  location,  and  then  dereferencing  that 
location. 


Figure  5.  Example  of  Hyper-Code  Representation  in  ProcessBase 


Our  current  HCR  design  for  PJama  is  similar  to  that  in  Figure  5,  although  it  is  less  elegant  due  to  the  relatively 
high  number  of  non- first-class  entities  to  which  it  must  support  linking  (methods,  array  elements,  fields,  types,  classes 
and  interfaces — compared  with  only  types  in  ProcessBase). 

3.3  System  Evolution 

Hyper-programming  is  also  the  basis  for  providing  new  solutions  to  the  problem  of  schema  editing  which  requires 
location  and  translation  of  affected  queries  and  data  [CCK-i-94a].  The  essential  elements  are  at  hand  in  the  hyper- 
pro^ammmg  system.  The  schema  may  keep  a  record  of  which  programs  (queries)  and  data  are  associated  with 
particular  parts  of  the  schema  via  secure  links.  The  programs  always  have  hyper-program  source  and  therefore  source 
code  and  data  translation  is  possible. 

The  schema  evolution  mechanism  transforms  the  programs  and  data  affected  by  a  schema  edit.  This  is  achieved  as 
follows: 

•  Locate,  from  the  schema,  all  affected  programs  and  data. 

•  For  each  program  which  may  be  affected,  obtain  its  hyper-program. 


A  simple  persistent  language  being  developed  as  part  of  the  Compliant  Systems  Architecture  project  [MBG+99a,  MBG+99b]. 
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•  Locate  the  points  in  the  hyper-program  which  access  the  changed  part  of  the  schema  and  edit  the  hyper-program 
to  reflect  the  hew  logical  schema  structure.  This  will  involve  establishing  new  links  both  to  and  from  the 
changed  part  of  the  schema. 

•  Update  the  old  program  with  the  new  one. 

•  Update  the  affected  data  with  new  versions. 

The  extent  to  which  this  process  can  be  automated  depends  upon  the  complexity  of  the  schema  change  incurred. 
The  essential  point  is  that  all  interrogation  and  manipulation  of  schema,  program  and  data  occurs  within  a  single 
integrated  environment,  and  may  therefore  be  represented  as  a  meta-level  program  within  that  environment. 

The  mechanism  relies  heavily  upon  the  self-contained  nature  of  the  persistent  environment.  As  all  the  data  and 
code  is  held  in  the  same  environment  as  the  schema,  it  is  possible  to  keep  not  only  links  from  the  schema  to  the  data  it 
describes  but  also  reverse  links  from  the  schema  to  programs  which  bind  to  particular  points  of  it.  The  hyper¬ 
programming  concept  makes  it  possible  to  map  between  executable  and  source  representations.  The  fact  that  these 
representations  are  themselves  values  within  the  persistent  environment,  along  with  the  provision  of  a  compiler  in  the 
same  environment,  makes  this  strategy  possible. 

3.4  Dependent  Types 

In  addition  to  data  access  checking  as  described  in  Section  2.2.1,  language  systems  also  perform  other  kinds  of 
checking  at  run-time,  some  of  which  can  be  performed  earlier  in  a  hyper-programming  system.  An  example  of  this  is 
dependent  type  checking  [CAB+93].  , 

A  dependent  type  is  a  type  that  depends  on  a  value.  In  general  this  requires  dynamic  type  checking.  To  determine 
whether  two  dependent  types  are  compatible,  the  hnguage’s  type  checker  takes  account  of  the  associated  values  as  well 
as  their  structure.  An  example  of  a  dependent  type  is  the  generic  type  map  [ALP+91],  instances  of  which  are  asso¬ 
ciations  between  sets  of  values.  The  type  of  a  particular  map  is  dependent  on  the  identity  of  the  procedme  that  defines 
equality  over  the  key  set.  Because  of  this  it  is  not  generally  possible  to  type-check  at  compilation-time  a  program  that 
contains  map  operations,  as  the  map  values  themselves  must  be  tested. 

In  a  hyper-programming  system  the  value  on  which  a  dependent  type  depends  may  be  linked  directly  into  a 
program,  and  may  thus  be  available  for  checking  at  compilation-time.  This  makes  it  possible  for  the  system  to  check 
operations  on  dependent  types  at  compilation-time  rather  than  planting  code  in  the  executable  program  to  perform  the 
checking  at  run-time.  The  system  may  also  provide  tools  that  allow  the  programmer  to  verify  the  type  compatibility  of 
selected  values  before  they  are  linked  into  the  hyper-program. 

More  generally  the  programmer  may  perform  arbitrary  checks  on  data  values  before  linking  them  into  a  hyper- 
program,  by  writing  and  executing  other  programs  that  compute  over  them.  If  the  checks  succeed,  the  code  that 
performs  the  checking  can  then  be  omitted  from  the  main  hyper-program,  since  the  links  to  the  original  values  are 
guaranteed  to  remain  intact. 

3.5  Internet  Programming 

The  potential  association  between  the  concept  of  hyper-programming,  and  the  Web,  is  obvious.  The  source  format 
of  hyper-programs  is  similar  to  hyper-text,  and  the  Web  provides  a  well-known  hyper-text  system  Over  the  global 
autonomous  network.  The  clear  appeal,  therefore,  is  to  somehow  extend  the  paradigm  to  make  it  work  in  this  context. 

This  appeal,  however,  is  fraught  with  serious  technical  difficulty,  and  it  would  be  over-ambitious  and  pre-emptive 
to  attempt  to  document  it  fully  in  this  paper.  We  therefore  restrict  the  discussion  to  an  elaboration  of  the  problems 
involved,  and  outline  strategies  which  we  believe  may  eventually  provide  solutions. 

Problems  exist  in  the  following  categories: 

•  how  can  program  source  be  represented? 

•  how  can  typed  data  be  integrated  with  the  http  protocol? 

•  how  could  data  deriving  from  other  web  sources  be  integrated  in  a  typed  computation? 

•  how  can  the  potential  failure  of  references  be  made  tolerable? 

3.5.1  Program  Source 

To  be  properly  compatible  with  the  Web,  it  is  necessary  to  represent  hyper-programs  in  HTML.  In  hyper- 
programming  prototypes,  program  source  is  represented  in  a  proprietary  format,  manipulated  only  by  specially  written 
editor/browser  software.  This  allows  the  presentation  of  the  program  source  to  the  programmer  to  be  strongly  associated 
with  the  programming  language  definition.  It  should  be  mentioned  that  one  of  the  known  (and  unsolved)  problems  of 
hyper-programming  is  how  standard  language  treatments,  such  as  the  definition  of  typing  and  semantics,  can  be  applied 
to  a  non-text-based  program  representation.  In  the  context  of  the  Web,  however,  a  solution  to  this  problem  is  forced. 
The  presentation  of  an  HTML  document  to  a  user  is  a  significant  abstraction  over  its  textual  representation.  The 
meaning  of  a  hyper-program  should  clearly  be  based  on  the  programmer’s  view:  the  problem  is  therefore  how  the 
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meaning  of  a  program  can  be  defined  when  the  textual  representation  of  the  source  is  different  fi-om  this  view 

Two  approaches  to  overcome  this  problem  are  based  on  the  definition  of  a  two-level  programming  algebra  and  the 
use  of  linguistic  reflection  as  a  language  definition  technique.  This  approach  is  based  upon  the  use  of  corapile-time 
reflection,  as  defined  in  [SFS+90].  A  subset  of  HTML  is  defined  as  the  core  programming  algebra,  making  it  relatively 
straightforward  to  define  the  semantics  of  both  standard  language  features  and  hyper-links  within  programs.  A  hyper¬ 
text  based  view  of  programs,  as  presented  to  the  programmer  in  both  specialist  program  editors  and  standard  browsers 
can  be  defined  (using  the  terminology  of  [SSS+98])  as  a  reflective  sub-language,  which  is  used  to  generate  the  HTML- 
based  textual  form  during  static  analysis  by  the  programming  system.  The  same  treatment  may  be  extended  to  give  a 
consistent  definition  of  the  implicit  transformation  of  free  variables,  as  performed  by  the  Napier88  hyper-programming 

Using  linguistic  reflection  as  a  definitional  framework  gives  a  well-defined  formal  framework  in  which  hyper¬ 
programs  can  be  described  using  relatively  conventional  definition  techniques.  Furthermore,  and  this  is  indeed  the  main 
motivation,  it  gives  a  framework  wherein  the  core  definition  of  hyper-programs  is  indeed  text-based,  thus  allowing  their 
transportation  around  the  various  text-based  protocols  of  the  Internet,  without  resorting  to  ad-hoc  translation  techniques. 

3.5.2  Typed  Data 

Given  a  persistent  programming  language  which  can  be  used  to  program  over  embedded  URLs,  the  next  step  is  to 
consider  how  a  URL  can  be  used  to  refer  to  typed  data,  even  supposing  that  the  URL  refers  to  data  generated  by  the 
same  pro^amming  system.  The  problem  in  turn  decomposes  into  three  further  issues,  These  are; 

•  unifying  the  global  persistent  namespace  with  those  namespaces  used  in  the  Web; 

unifying  the  representation  of  the  typed  persistent  data  with  that  commonly  used  on  the  Web,  namely  HTML; 

•  introducing  type  system  primitives  which  allow  the  integration  of  remote,  unreliable,  and  autonomous  data  with 

an  otherwise  static  type  system.  ’ 

3.5.3  Importing  Data 

^  The  full  potential  of  a  web-based  hyper-programming  system  would  only  be  met  if  it  were  possible  to  include  links 
to  data  which  had  been  generated  by  some  system  other  than  the  particular  programming  language  in  use.  Once  again, 
this  is  an  enormous  issue  and  can  not  be  addressed  in  this  short  space.  There  are  two  simple  solutions:  the  first  is  to  read 
the  data  as  text  or  MIME,  and  restrict  the  typing  of  such  links  according  to  its  transmitted  classification.  This  results  in  a 
^e  safe  language  but  does  not  really  address  the  spirit  of  the  problem.  The  other  simple  solution  is  to  publish  the 
format  used  for  the  system’s  own  typed  data,  and  ensure  it  is  possible  to  generate  that  externally.  Once  again  this  is  not 
really  a  solution  to  the  problem. 

The  more  ambitious  goal  is  to  attempt  to  analyse  arbitrary  data  resulting  from  an  http  request  for  appropriate 
structural  content  and,  if  it  is  suitable,  integrate  it  into  a  typed  computation.  The  outline  of  our  approach  is  for  the 
programmer  to  specify  a  required  type  for  the  binding  during  the  composition  process.  The  URL  is  duly  fetched,  and 
translated  into  a  semi-stmctured  format  according  to  a  number  of  ad-hoc  rules,  probably  also  governed  by  the 
programmer  Having  achieved  a  semi-structured  representation  of  the  data,  the  programmer’s  asserted  type  is  used  to 
denve  a  subset  of  the  data  which  corresponds  to  the  same  structure.  This  data  is  extracted  and  incorporated  into  the 
ongoing  computation.  An  estimation  of  how  well  the  data  fits  the  expected  type  is  also  generated,  and  may  be  either 
returned  to  the  user  of  the  program  or  used  within  the  running  program. 

Although  we  have  evidence  that  the  outline  given  above  is  possible  to  engineer,  and  furthermore  gives  a  viable  and 
understandable  programming  system,  each  of  the  steps  described  presents  its  own  major  problems  and  the  production  of 
such  an  integrated  programming  system  is  still  beyond  current  understanding. 


3.6  An  Open  C++/DCOM  Hyper-programming  Environment 

In  this  section  we  report  on  an  attempt  to  apply  the  hyper-programming  model  in  the  context  of  an  open  system 
We  chose  a  DCOM/C++  system  for  the  experimentation  for  a  number  of  reasons.  Firstly,  both  C++  [Str86]  and  DCOM 
[Mic96]  are  being  used  by  a  large  number  of  programmers  to  build  systems  in  the  real  world.  Secondly  having 
programmed  with  DCOM  and  C++,  we  felt  there  was  a  high  degree  of  accidental  complexity  associated  with  this  style 
that  was  not  intrinsic  in  the  problem  domain.  We  hoped  that  hyper-programming  might  be  used  to 
simplify  the  construction  of  DCOM  programs.  Finally  we  were  influenced  by  the  HIPPO  work  of  Connor  rcSM98]  and 
sought  to  discover  if  C++/DCOM  programs  could  be  written  which  had  the  same  flavour  as  Hippo  programs.  If  this  was 
possible,  the  power  of  the  many  C++  libraries  and  environments  could  be  used  cheaply  construct  Web  utilities.  In 
addition  to  creatmg  a  hyper-programming  environment  for  a  commercial  system,  a  deliberate  attempt  was  made  to 
maximise  the  use  of  freely  available  software  and  to  avoid  writing  new  software  whenever  possible. 


The  ad-hoc  nature  of  this  part  of  the  process  can  be  entirely  circumvented  when  the  document 
Standard  for  Web  information. 


is  XML,  which  we  perceive  to  be  a  rapidly  emerging 
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3.6.1  Hyper-Program  Construction 

A  DCOM/C++  hyper-program  is  constructed  using  two  tools:  a  text  editor  and  a  binder.  These  are  used  to  specity 
the  hyper-program  text  and  the  hyper  links  respectively.  The  output  from  these  tools  is  fed  into  a  pre-processor  which 
unifies  the  source  and  the  links  into  standard  C++  prior  to  presentation  to  the  gnu-C++  compiler.  The  pre-processor  also 
creates  files  and  directories  for  cache  maintenance  and  in  some  circumstances  pre-fetches  Web  pages. 


3.6.2  Editing  Environment 


The  first  tool  requirement  was  for  a  text  editor  capable  of  incorporating  hyperlinks  and  suitable  for  editing 
programs.  Web  editing  tools  such  as  Netscape  Composer  and  FrontPage  do  not  support  the  editing  of  programs  since 
they  are  intended  as  HTML  composition  tools.  Consequently  Eraacs  [StaSl]  was  used  with  a  (then)  freely  available 
extension  called  Hyperbole  [Alt98].  Hyperbole  supports  the  inclusion  of  hyperlinks  into  documents.  In  particular,  these 
links  can  refer  to  Uniform  Resource  Locators  (URLs),  i.e.  web  pages,  and  can  be  clicked  on  with  the  mouse.  A 
Hyperbole  user  works  with  buttons  embedded  within  textual  documents.  These  buttons  may  be  created,  modified, 
moved  or  deleted.  Each  button  performs  a  specific  action,  such  as  linking  to  a  file  or  executing  a  shell  command.  Figure 
6  shows  a  C++  hyper-program  being  edited  with  the  Emacs/Hyperbole  environment. 


void  main  (char*'*'  argv,  int  argc)  Create  hyper-link 

^  BDDL  end  =  FflLSEj  -  hyper-link 

BOOL  is^found  =  FALSE;  Belete  hyper-link 

OLECHFiR  *line;  !it*»*#******;i:*'t:*******j.i; 

IHTHL*h  =  I 

while (SUCCEEDED (h->at  end(  Activate-Button-at-Polnt 
if ((SUCCEEDED^h->f  Back-to-Prior-Location 

■  ,  printf (  ”D  Button-File 

■break;  Docunentatioi 

■  if  (  FAILED  (h->nextj!£i,j,.^,.^-.,„.™..... _ _ 


found))  &8>  is_found)) 


printf (  "didn’t  find  ^s’ 


Figure  6.  Emacs  and  Hyperbole 


3.6.3  The  Hyper-Program  Source  Code 

This  program  shown  in  Figure  7  contains  a  C++/DCOM  hyper-program  that  finds  the  telephone  number  of  a 
member  of  the  Computer  Science  Department  at  Glasgow  University.  It  does  this  by  scanning  an  HTML  page  denoted 
by  the  hyperlink  telephonedirectory.  The  program  creates  a  binding  denoted  by  h  of  type  IHTML*  to  this  Web  page. 
The  IHTML  class  shown  in  Figure  8,  permits  a  supports  a  number  of  operations  including  the  findjnjine  method 
which  searches  lines  of  the  page  looking  for  the  sub-string  specified  in  the  parameter.  If  a  match  is  found  the  line  is 
returned.  It  also  contains  a  predicate  at  end  mdicating  that  the  end  of  the  page  has  been  reached. 
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void  main  (char**  argv,  int  argc) 

{ 

BOOL  end  =  FALSE; 

BOOL  is_found  =  FALSE; 

OLECHAR  *line; 

lHTML*h  =  < (telephonedirectory) >; 

while (SUCCEEDED (h->at_end (&end) )  &&  !  end)  { 

if ( (SUCCEEDED (h->fiad_in_line (argv [1, &line, &is_foimd) )  &&  is  found)) 
{ 

printf (  ®  Details  are  %s  VnXr*  ,  line  )  ; 
break ; 

} 

if (  FAILED (h- >next_line 0 )  )  i 

break ; 

} 

if (  end  ) 

printf  (  "  didn't  find  %s'',  argv[l]); 


Figure  7.  A  C++/DCOM  Hyper-Program 


interface  IHTML  :  lunknown 

{ 

HRESULT  display_line(); 

HEESULT  openURL([in,  string]  char*  filename); 

HRESULT  next_line ( ) ; 

HRESULT  find_in_line(  [in,  string]  char*  name, 

[string,  out]  OLECHAR**  line, [out]  int*  isfound) ; 

HRESULT  at_end([out]  int  *i) ; 

} 

Figure  8.  MIDL  Definition  of  the  IHTML  Interface 
The  code  shown  in  Figure  7  is  standard  DCOM/C++  except  for  the  line, 

IHTML*h  =  < (telephonedirectory) >; 

which  has  to  be  replaced  with  standard  C++,  as  described  above  this  task  is  performed  by  the  pre-processor.  The 
code  sequence  into  which  this  hyper-link  is  expanded  depends  on  the  binding  style  specified  in  the  binder.  This  is 
described  the  next  section. 

3.6.4  Creating  Bindings 

Using  the  Hyperbole  environment,  bindings  can  be  made  to  any  Web  based  data.  However,  this  does  not  address 
the  need  to  specify  attributes  associated  with  those  links  such  as  programming  language  type,  external  data  type,  the 
location  of  the  data  being  bound  and  binding  time.  To  allow  hyper-programmers  to  specify  and  view  bindings,  a  Web 
interface  to  a  binder  has  been  created  and  is  shown  in  Figure  9.  ’ 

The  binder  permits  users  to  specify  a  name  for  a  hyper-link.  This  is  used  to  match  the  hyper-links  entered  in  the 
editor  with  bindings  specified  in  the  binder.  The  next  field  is  the  type  of  the  object  in  the  programming  language 
context.  In  the  current  implementation  this  field  contains  a  string  which  is  used  to  specify  the  programming  language 
type  of  the  target  object.  This  field  is  strictly  unnecessary  since  it  could  be  automatically  generated  but  makes  the 
generated  code  more  readable.  The  next  field,  IID,  is  used  to  specify  the  type  (interface)  of  the  object  being  linked  to.  In 
the  example  shown  in  Figure  9,  the  link  is  to  an  object  of  type  IHTML,  shown  in  Figure  8.  The  CLSID  field  is  used  to 
specify  a  class  library  containing  executable  code  implementing  the  class  specified  in  the  HD  field.  For  DCOM 
aficionados,  this  is  used  to  find  by  a  class  moniker  to  locate  the  class  object,  The  URL  field  specifies  the  location  of  the 
data  to  which  the  link  refers . 

The  last  field  is  used  to  specify  the  time  at  which  the  binding  is  resolved.  There  are  currently  two  options 
supported:  compile  time  and  run  time.  These  settings  change  the  behaviour  of  the  pre-processor  and  cause  different 
code  to  be  generated.  When  the  compile-time  option  is  chosen  the  pre-processor  pre-fetches  a  copv  of  the  target  and 
stores  it  locally.  In  this  case  the  code  generated  contains  fewer  run-time  checks  since  the  data  will  always  be  accessible. 
When  run-time  binding  is  employed,  failure  at  run-time  is  possible  and  consequently  the  generated  code  needs  to  be 
more  sophisticated.  The  code  generated  for  the  example  program  shown  in  Figure  7  is  given  in  the  next  section. 
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Figure  9.  Entering  Details  into  the  Binder 


3.6.5  Binding  Times  and  Errors 

The  code  generated  depends  on  the  binding  time  specified  in  the  binder.  Figure  10  shows  a  slightly  simplified 
version  of  the  code  generated  for  the  hyper-program  shovm  in  Figure  7  if  construction  time  (eager)  binding  is  specified. 
This  code  assumes  that  the  binder  has  loaded  the  Web  page  into  the  local  cache  (home/sag/cache).  The  dynamic  case  is 
similar  but  requires  additional  code  to  fetch  the  page  across  the  network.  The  code  generated  is  straightforward  DCOM 
code. 

void  main(int  argc,  char**  argv) 

{ 

OLECKAR  *lin.e  =  0; 

IHTML*  h  =  0; 

IClassFactory  *pcf  =  0;  , 

HRESULT  res  =  S_OK; 

IMoniker  *pmk  -  0; 

IBindCtx  *pbc  =0; 

Check (CreateBindCtx (0,  &pbc) ,  "CreateBindCtx  failed"); 

Check (CreateClassMoniker  (CLSID_CWebObject,  &pmk) ,  "CreateClassMoniker  failed"); 

Check (BindToObject (pbc, 0, IID_IClassFactory, (void**) &pcf) ,  "BindToObject  failed"); 

Check (pcf->Createln3tance (0,  IID_IHTML,  {void**)&h),  "Create  Instance  failed"); 

Check (h->openURL (  "/home/sag/cache/www.dcs.gla.ac.uk/contact/index.html") , 

"Open  ORL  failed"); 

BOOL  end  =  FALSE; 

BOOL  is_found  =  FALSE; 

while ( SUCCEEDED (h->at_end( fiend) )  fifi  !  end)  { 

if ( (SUCCEEDED(h->find_in_line (argv [1, filine, &is_found) )  fifi  is_found) )  { 
printf  (  "  Details  are  %s  \n\r’'  ,  line  )  ; 
break ; 

if (  FAILED (h- >next_line () )  ) 
break ; 

} 

if (  end  ) 

printf  (  *  didn't  find  %b",  argv[l]); 
h->Release ( ) ; 

'  pcf->Release ( ) ; 

}  . 

Figure  10.  Simplified  DCOM  code  generated  for  Figure  7 


3.6.6  Future  Directions 

All  the  examples  and  screen  shots  discussed  this  far  describe  a  system  that  has  been  implemented  at  the  University 
of  Stirling.  However,  this  code  represents  the  start  rather  than  the  end-point  of  what  we  are  trying  to  achieve.  We  stated 
earlier  that  we  were  seeking  an  integration  of  C++/DCOM  with  hyper-programming  and  the  ideas  embodied  in  the 
Hippo  system.  We  now  describe  how  we  can  use  what  we  have  implemented  to  date  to  achieve  this. 


void  main  (char**  argv,  int  argc) 

BOOL  end; 

IPersonSet  *s  =  <(telephonedirectory)>; 
while (S0CCEEDED (s->at_end (Send) )  &&  lend)  { 

Person  person; 

if  (SUCCEEDED  (s->next_person(sperson)  &&  !strcrtip(person.name,argv[l] ) ) )  ( 
printf ("Telephone  number  of  %s  is  %s\n",argv[l] , person. phone_no) ; 

} 

} 

^  if  (end)  printf ("didn't  find  %s\n", argvtl] ) ; 

Figure  11.  A  Strongly  Typed  C+4-  Hyper-Program 

The  pro^am  shown  in  Figure  7  treats  the  Web  data  as  an  HTML  file  not  as  a  typed  entity.  We  would  like  to  be 
able  to  re-write  the  hyper-program  as  shown  in  Figure  1 1.  In  this  example,  rather  than  treating  the  data  as  HTML  text 
we  have  typed  it  as  a  set  of  objects  of  type  Person.  This  requires  a  number  of  refinements  to  the  mechanisms  already 
implemented.  Fnst  the  HTML  file  must  be  typed  as  a  set  of  Person.  To  achieve  this,  a  MIDL  interface  definition  of  a 
set  of  Person  is  created  as  shown  in  Figure  12.  This  type  is  structurally  similar  to  the  IHTML  interface  given  earlier 
with  the  line  type  being  replaced  with  records  of  type  Person.  Since  the  IPersonSet  interface  inherits  from  IHTML  it 
may  use  the  IHTML  interface  to  assist  in  the  extraction  of  records  of  type  Person  from  the  text  file. 

typedef  struct  {  OLECHAR  *name;  OLECHAR  *phone_no;  OLECHAR  *nickname;  }  Person; 

interface  IPersonSet  :  IHTML 

{ 

HRESULT  next_perBon( [out]  Person*  current  ) ; 


Figure  12.  MIDL  Definition  of  Person  Set  Interface 

Some  mechanism  must  be  provided  to  convert  the  textual  data  retrieved  over  the  Web  into  typed  objects  (in  this 
case  of  type  Person).  This  task  is  encoded  in  the  library  providing  the  implementation  of  IPersonSet.  Whilst  this 
implementation  could  be  hand  coded,  a  more  desirable  approach  would  be  to  generate  it  automatically  from  a 
specification.  There  are  two  basic  approaches  to  this;  (1)  use  the  MIDL  as  a  specification  for  the  Web  format  and  (ii)  use 
the  Web  format  as  a  specification  to  generate  the  MIDL. 

If  the  first  approach  were  employed,  a  tool  could  be  engineered  which  took  the  MIDL  interface  and  a  URL  as 
par^eters  and  attempted  to  find  records  of  the  appropriate  type  in  the  file.  In  the  case  of  the  URL  used  in  the  examples 
m  this  Section,  the  fields  are  all  comma  separated  making  this  task  easy.  This  is  similar  to  the  construction  of  indices  in 
database  systems  and  the  importation  of  records  using  Wizards  in  Microsoft  Excel  and  Access.  Once  the  index  was 
created,  generic  code  could  be  used  to  traverse  the  data  and  return  records  each  time  next _person  was  called.  An 
alternative  approach  is  to  generate  the  IDL  from  the  Web  source.  This  approach  is  particularly  attractive  if  the  Web 
source  is  encoded  in  a  structured  or  semi-structured  manner,  for  example,  using  XML  [BPS98].  In  both  cases,  generic 
code  needs  to  exist  which  may  be  specialised  to  operate  over  records  of  an  appropriate  type.  This  may  be  achieved 
using  the  parametric  polymorphism  provided  by  the  implementation  language  or  using  tools  such  as  those  suggested  bv 
Sheard  and  Stemple  [SSF92]  or  Kirby  [KCM94].  bb  y 


4  Conclusions 


Our  original  motivation  for  hyper-programming  was  to  allow  the  user  to  compose  programs  interactively 
navigating  the  environment  and  selecting  data  items,  including  code,  to  be  incorporated  into  the  programs  We  further 
believed  that  programming  language  systems  could  provide  better  support  for  the  software  engineering  process  than 
^wlopm^^  ^present,  in  particular,  with  regard  to  the  traditional  compose-compile-link-execute  cycle  of  program 

From  our  early  implementations  of  hyper-programming  we  summarised  that  the  attendant  benefits  of  the  concept 
/ 

•  being  able  to  perform  program  checking  early 

•  support  for  source  representations  of  all  object  closures 
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•  being  able  to  enforce  associations  from  executable  programs  to  source  programs 

•  availability  of  an  increased  range  of  linking  times 

•  increased  program  succinctness 

•  increased  ease  of  program  composition 
Here  we  have  developed  the  hyper-programming  notion  to  presenting  a  single  representation  of  data  and  code 

throughout  the  software  process  using  hyper-code.  Furthermore  we  have  explored  techniques  for  adapting  hyper¬ 
programming  to  persistent  contexts  that  do  not  enforce  referential  integrity,  such  as  the  WWW;  and  implementing  and 
using  hyper-programming  in  standardised  languages  and  inter-operability  mechanisms,  such  as  C-i-i-  and  DCOM. 
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Abstract.  Traditional  database  systems  use  ACID  properties  (Atomicity,  Consistency,  Isolation  and  Durability)  to 
implement  recovery  and  concurrency  control.  However,  this  implementation  is  not  always  appropriate  in  distributed 
real  time  systems  and  in  systems  with  long-lived  transactions.  For  example,  long-lived  transactions  may  be  active  for 
days,  and  at  the  same  time  other  transactions  may  need  access  to  data,  locked  by  the  long-lived  transactions. 
Therefore,  extended  transaction  models  have  been  developed.  T^hese  transaction  models  only  implement  semantic 
ACID  properties.  That  is,  from  an  application  point  of  view  the  system  should  function  as  if  the  traditional  ACID 
properties  were  implemented. 

Multi  user  word  processing,  CAD  and  CASE  systems  may  both  be  distributed  and  have  long-lived  transactions, 
Therefore,  extended  transaction  models  may  be  useful  in  Computer  Supported  Cooperative  Work  (CSCW),  where 
users  work  with  shared  data.  In  this  paper  we  will  try  to  integrate  tire  research  in  extended  transaction  models  with  the 
CSCW  research,  which  for  m^y  years  have  been  aware  of  the  shortcomings  of  the  traditional  ACID  properties. 

In  the  transaction  model  in  this  paper  the  global  atomicity  property  is  implemented  by  combining  the  possibilities  of 
either  forcing  the  remaining  updatings  of  a  transaction  to  be  executed  or  compensating  the  already  executed 
updatings  of  the  transaction.  The  global  consistency  property  may  be  managed  by  the  CSCW  system  md/pr  by 
humra  beings  supported  by  tools.  The  global  isolation  property  is  implemented  by  using  countermeasures  to  the 
missing  isolation  of  the  updating  transactions.  The  global  durability  property  is  implemented  by  using  the  durabilitv 
property  of  the  local  CSCW/DBMS  systems. 

In  the  extended  transaction  model  described  above  we  will  incorporate  some  of  the  most  promising  CSCW 
commit/isolation  features  known  from  the  scientific  CSCW  literature. 

KEYWORDS.  CSCW,  distributed  groupware,  collaborative  writing,  semantic  ACID  properties,  concurrency  control 
long-lived  transactions  ’ 


1  Introduction 


CSCW  systems  may  be  grouped  in  synchronous  and  asynchronous  groupware  systems. 

In  synchronous  ^oupware  systems  all  modifications  can  be  observed  real-time  by  all  members  of  the 
collaboration.  These  WYSIWIS  (What  You  See  Is  What  I  See)  systems  (Stefik  et  al.,  1987)  do  not  have  a  well-defined 
transaction  concept,  and,  therefore,  the  ACID  properties  of  such  systems  are  not  will  defined  either  Anyway 
synchronous  systems  do  have  consistency  problems,  and,  therefore,  the  tools  of  our  transaction  model  may  improve  the 
situation. 

In  asynchronous  groupware  systems  (e.g.  Koch,  1995  and  Jones,  1995)  a  user  may  first  modify  his/her  local 
version  of  the  database/document.  When  the  modifications  of  the  user  are  ready  to  be  published  to  the  other  users  a 
global  updating  transaction  is  executed,  and  in  this  situation  the  semantic  ACID  properties  of  our  transaction  model 
may  be  important. 

^  In  synclmonous  groupware  systems  traditional  locks  can  normally  not  be  recommended  as  they  slow  down  the  real 
time  interaction  of  the  users.  In  asynchronous  systems  locking  cannot  be  recommended  either,  when  some  of  the 
transartions  are  long-lived  (Gray  and  Reuter,  1993).  The  problem  is  that  locking  long-lived  transactions  exclude  other 
updatings,  and  this  may  not  be  acceptable.  Therefore,  traditional  locking  is  normally  not  used  in 
CSCW  systems,  which  for  many  years  have  used  different  countermeasures  that  can  reduce  the  problems  occurring 
when  traditional  locking  cannot  be  used  for  concurrency  control. 

"^e  objective  of  this  paper  is  to  illustrate  how  to  integrate  different  commit/isolation  protocols  to  facilitate  the 
selection  of  the  right  combinations  of  properties/tools  for  a  CSCW  system  in  a  specific  application  area. 

The  paper  is  organized  as  follows:  Section  2  will  describe  the  transaction  model  used  in  this  paper,  i.e.  we  will  give 
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an  overview  of  how  the  global  semantic  ACID  properties  can  be  implemented.  In  section  3  we  will  illustrate  how  to 
integrate  different  commit/isolation  protocols  for  CSCW  systems.  Concluding  remarks  are  presented  in  section  4. 

Related  work:  The  systematic  analysis  of  countermeasures,  described  in  Frank  and  Zahle  (1998),  was  not  possible 
until  the  isolation  property  was  decomposed  into  disjunctive  isolation  anomalies  by  Gray  and  Reuter  (1993)  and 
Berenson  et  al.  (1995). 

For  many  years,  extensive  research  has  been  made  in  CSCW  systems  with  shared  data  in  order  to  bypass  the 
problems  of  traditional  concurrency  control.  (For  example  Ellis  and  Gibbs,  1989;  Pacull  et  al.,  1994;  Koch,  1995;  Jones, 
1995  and  Salcedo  et  al.,  1997).  This  paper  may  be  viewed  as  a  supplement  to  this  field  of  research,  where  we  use  the 
disjunctive  consistency  problems  of  Gray  and  Reuter  (1993)  to  describe  in  more  detail  the  properties  of  the  different 
commit/isolation  protocols. 

The  commMsolation  protocols  may  be  described  by  rules.  Therefore,  the  commit^isolation  protocols  may  be 
implemented  by  using  the  flexible  CSCW  systems  as  described  in  e.g.  Georgakopoulos  et  al.  (1994)  and  Rusinkiewitz 
et  al.  (1995),  where  the  rules  of  the  transactions  are  defined  by  there  activity  type.  In  other  words,  it  is  possible  to 
change  the  commit/isolation  protocol  by  changing  the  activity  type  of  the  transactions. 

2  The  Transaction  Model 

In  the  following,  we  will  give  an  overview, of  how  the  global  semantic  ACID  properties  are 
implemented  in  our  transaction  model. 

2.1  The  Atomicity  Property 

An  updating  transaction  has  the  atomicity  property  and  is  called  atomic  if  either  all  or  none  of  its  updatings  are 
executed.  In  this  paper  we  use  the  single  pivot  transaction  model  (Mehrotra  et  al.,  1992;  Zhang  et  al.,  1994  and  Frank, 
1999)  for  atomicity  implementation.  In  this  transaction  model  the  global  transaction  is  partitioned  into  the  following 
types  of  subtransactions  that  are  executed  at  different  locations; 

1.  The  phot  subtransaction  that  manages  the  atomicity  of  the  global  transaction,  i.e.  the  global  transaction  is 
committed  globally  when  the  pivot  subtransaction  is  committed  locally.  If  the  pivot  subtransaction  aborts,  alfthe 
updatings  of  the  other  subtransactions  must  be  compensated  or  not  executed. 

2.  The  compensatable  subtransactions  that  all  may  be  compensated.  Compensatable  subtransactions  must  always 
be  executed  before  the  pivot  subtransaction  is  executed  in  order  to  allow  them  to  be  compensated  if  the  pivot 
subtransaction  cannot  be  committed.  Compensation  is  achieved  by  executing  a  compensating  subtransaction. 

3.  The  retriable  subtransactions  that  are  designed  in  such  a  way  that  the  execution  is  guaranteed  to  commit  locally 
(sooner  or  later).  Retriable  subtransactions  are  executed  after  the  local  commit  of  the  pivot  subtransaction,  because  they 
have  the  pivot  subtransaction  as  parent  and  are  initiated  by  the  pivot  subtransaction. 

Example 

When  a  primary  copy  of  an  object  is  updated,  created  or  deleted,  the  secondary  copies  may  be  updated  with 
global  atomicity  by  using  retriable  subtransactions.  Suppose  all  users  in  a  CSCW  system  have  their  own  local 
workspace  copy  of  a  database,  where  a  primary  copy  of  the  database  is  used  to  serialize  and  distribute  the  updating 
transactions.  In  this  situation  an  updating  user  can  send  compensatable  subtransactions  to  the  other  users  via  the 
primary  copy  location.  All  the  updatings  of  the  compensatable  subtransactions  must  be  marked  as  compensatable.  If 
the  other  users  can  accept  the  updatings  from  the  compensatable  subtransaction,  they  send  an  accept  message  to  the 
primary  copy  location.  If  the  primary  copy  location  recefves  accept  messages  from  all  the  involved  users,  a  pivot 
subtransaction  can  commit  the  updatings  globally  by  committing  the  updatings  in  the  primaty  copy  location.  After 
this,  retriable  subtransactions  initiated  by  the  pivot  subtransaction  are  sent  to  all  the  users  to  de-mark  the 
compensatable  mark  of  the  updatings  committed  at  the  primary  copy.  The  same  retriable  subtransactions  may  also 
try  to  upgrade  any  other  compensatable  marked  updatings  to  the  new  object  version. 

2.2  The  Consistency  Property 

A  database  is  consistent  if  the  data  in  the  database  obeys  the  consistency  rules  of  the  database.  Consistency  rules 
may  be  implemented  as  a  control  program  that  rejects  transactions,  which  do  not  obey  the  consistency  rules. 

In  CSCW  systems  consistency  rules  may  be  managed  by  the  CSCW  system  if  they  are  described  and  initiated  by  a 
user  (See  e.g.  Decouchant  et  al.,  1996). 
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2.3  The  Isolation  Property 

A  database  where  all  the  transactions  have  the  consistency  property  may  still  be  inconsistent,  if  the  isolation 
property  is  missing.  A  transaction  is  executed  with  the  isolation  property  if  the  updatings  of  the  transaction  only  are 
seen  by  other  transactions  after  the  updatings  of  the  transaction  have  been  committed. 

In  our  transaction  model  the  global  semantic  isolation  property  is  managed  by  using  countermeasures  against  the 
isolation  anomalies  that  occur  when  transactions  are  executed  without  the  isolation  property.  In  designing 
countermeasures  it  is  possible  to  use  local  locking,  but  all  locks  should  be  released  immediately  after  a  subtransaction 
has  been  committed/aborted  locally  in  order  to  avoid  blocked  data  (Data  is  blocked  if  it  is  locked  by  a  subtransaction 
that  loses  the  connection  to  the  parent  transaction). 

If  the  isolation  property  is  not  implemented,  four  different  types  of  isolation  anomalies  may  occur.  And  if  none  of 
these  isolation  anomalies  can  occur,  the  execution  of  tlie  transactions  is  serializable  (Gray  and  Reuter,  1993  and 
Berenson  et.  al.,  1995).  In  the  following  we  will  describe  the  tree  isolation  anomalies  that  are  important  in  CSCW 
systems: 

1. The  lost  update  anomaly  is  by  definition  a  situation  where  a  first  transaction  reads  an  object  for  update 
without  using  locks.  Subsequently,  the  object  is  updated  by  another  transaction.  Later,  the  first  transaction  (based 
on  its  earlier  read  value)  updates  the  object  and  commits. 

In  our  transaction  model  all  the  local  users  have  there  own  copy  of  the  database  and  reading/updating  the 
local  database  copy  functions  as  reads  for  update  without  locks.  In  such  a  situation  it  is  possible  for  conflicting 
transactions  to  update  the  same  object,  and  only  the  updating  of  the  last  transaction  will  survive. 

2.  The  dirty  read  anomaly  is  by  definition  a  situation  where  a  first  transaction  updates  an  object  without 
locking  the  object  or  committing  the  update.  After  this,  a  second  transaction  reads  the  object.  Later,  the  first 
update  is  aborted  (or  compensated).  In  other  words,  the  second  transaction  has  read  a  version  of  the  object  that 
was  never  committed  and  therefore  never  really  did  exist. 

In  our  transaction  model  the  dirty  read  anomaly  may  happen  when  the  first  transaction  updates  an  object  by 
using  a  compensatable  subtransaction  that  is  distributed  to  all  the  local  databases  of  the  users.  Later,  these 
distributed  updatings  are  removed  by  using  compensating  subtransactions.  If  a  local  user  reads  the  object  before 
it  is  compensated,  the  data  read  will  be  dirty  and  may  result  in  a  wrong  decision. 

3.  The  non-repeatable  read  anomaly  ox  fuzzy  readxs  by  definition  a  situation  where  a  first  transaction  reads 
an  object  without  using  locks.  This  object  is  later  updated  and  committed  by  a  second  transaction  before  the  first 
transaction  has  been  committed.  That  is,  if  the  first  transaction  rereads  the  object,  the  attributes  of  the  object  are 
changed,  In  other  words,  the  second  transaction  may  read  something  that  is  not  true  when  the  transaction 
commits,  and  this  may  result  in  a  wrong  decision. 

In  our  transaction  model  this  may  happen  when  the  first  transaction  reads  an  object  in  the  local  copy  of  the 
database.  Later  the  same  object  may  be  updated  by  a  retriable  subtransaction  without  the  local  user  noticing  the 

update,  which  may  cause  the  local  user  to  make  wrong  decisions. 

2.4  The  Durability  Property 

Transactions  have  the  durability  property  if  the  updatings  of  the  transactions  cannot  be  lost  after  they  have  been 
committed.  For  global  atomic  transactions  the  global  durability  property  will  automatically  be  implemented,  as  it  is 
ensured  by  the  durability  of  the  local  databases  (Breibart  et.  al.,  1 992). 

3  Integration  of  the  Commit/lsolation  Protocols 

In  major  projects  group  structures,  roles,  and  activities  may  change  during  a  project.  Therefore,  according  to  e.g. 

Koch  (1995)  and  Jones  (1995),  it  should  be  possible  to  change  the  commit/isolation  procedure  while  the  oroiect  is 
running. 

All  the  commit/isolation  protocols  described  in  this  section  have  a  precisely  defined  commit  time,  after  which  an 
update  decision  cannot  be  annulled  automatically.  This  is  practical  from  an  implementation  point  of  view,  and  it  also 
suits  most  sfructured  working  situations.  However,  working  groups  (and  individuals)  do  not  always  work  in  a  structured 
way,  and,  therefore,  it  may  be  important  to  be  able  to  undo  already  committed  updatings.  In  this  situation  it  is  practical 
to  have  a  common  transaction  model  (like  our  transaction  model)  to  manage  the  transaction  back  out  independent  of  the 
commit/isolation  protocols  used  by  the  transaction  that  should  be  backed  out. 

In  this  section  we  will  illustrate  how  to  integrate  our  transaction  model  with  some  of  the  existing  commit/isolation 
protocols  described  in  the  scientific  literature. 
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3.1  The  Reread  Countermeasure 

Transactions  that  use  this  countermeasure  (Frank  and  Zahle,  1998)  read  an  object  twice  by  using  short  duration 
locks  for  each  reading.  If  a  second  transaction  has  changed  the  object  between  the  two  readings,  the  transaction  must 
abort  itself  after  the  second  read.  In  asynchronous  CSCW  systems  the  reread  countermeasure  may  be  used  to  protect 
against  the  lost  update  anomaly  in  the  following  way:  After  a  user  has  updated  his/her  local  workspace,  both  the  old 
version  (or  the  version  id.)  and  the  new  version  of  the  changed  objects  are  sent  to  the  primary  copy  location,  where  the 
primary  copy  of  these  objects  are  read.  If  the  primary  copies  of  the  objects  are  the  same  versions  as  the  user’s  old 
versions,  then  the  primary  copy  objects  are  modified  to  the  user’s  new  versions.  Otherwise,  the  updatings  of  the  user  are 
rejected,  and  the  committed  primary  copy  version  of  the  objects  may  be  displayed  for  the  user  in  a  special  color  as  a 
“non-repeatable  read”  warning.  Later,  the  user  may  upgrade  his/her  updatings  to  the  new  object  versions  and  retry  to 
submit  the  updating  transaction.  In  real  time  WYSIWIS  systems  it  may  be  very  confusing  if  different  users  delete, 
change  and/or  move  the  same  sentence/figure  element  independently  (Greenberg  and  Marwood,  1994).  In  this  situation 
the  reread  countermeasure  can  prevent  the  problem  in  the  following  way:  At  first,  new  updatings  are  executed  at  the 
location  of  the  updating  user  as  compensatable  updatings.  Later,  a  pivot  subtransaction  updates  the  primary  copy  if  it  is 
unchanged.  Finally,  the  committed  updatings  of  the  pivot  subtransaction  are  propagated  to  the  other  users.  However,  if 
the  primary  copy  vas  changed  by  another  user,  the  pivot  updatings  are  rejected  and  compensated  in  the  location  of  the 
updating  user.  . 

3.2  The  Version  Tree  Protocol 

If  different  parallel  versions  of  an  object  exist,  they  may  be  implemented  by  a  version  tree  (Koch,  1995),  where  the 
different  parallel  versions  are  children  of  the  same  parent  object.  The  following  example  illustrates  how  version  trees 
may  be  integrated  in  our  transaction  model. 

Example 

Insertion  of  a  new  subtext  (character  string)  into  an  object  is  implemented  as  a  new  object,  which  is  a  child  of 
the  original  object.  In  other  words,  different  transactions  can  create  different  versions  of  the  same  parent  object  by 
storing  different  child  objects  related  to  the  same  parent  object.  The  child  objects  are  identified  by  the  id  of  the 
parent  object  in  combination  with  the  id  of  the  updating  transaction  (and  possibly  a  sequence  number,  if  the 
updating  transaction  creates  many  child  objects).  A  field  value  in  the  child  object  marks  the  insertion  as 
"compensatable”  if  the  insertion  is  not  committed  globally.  A  compensatable  insertion  can  easily  be  committed 
globally  by  de-marking  the  corresponding  "compensatable"  mai’k.  However,  in  this  situation  other  compensatable 
marked  updatings  to  the  same  object  must  be  upgraded  to  the  new  version  of  the  object  as  described  in  the  next 
subsection.  A  computer  program  can  do  this,  but  the  upgraded  transactions  should  be  marked  with  “non-repeatable 
read  anomaly”  until  a  human  brain  has  accepted  the  upgraded  insertion  as  a  semantic  correct  insertion  to  the  new 
version  of  the  object.  If  a  human  cannot  accept  the  upgraded  insertion,  the  corresponding  transaction  must  be 
compensated. 

3.3  The  Operational  Transformation  Protocol 

The  objective  of  the  distributed  OPperational  Transformation  (dOPT)  Algorithm  described  in  Ellis  and  Gibbs 
(1989)  is  to  implement  concurrency  control  in  real  time  groupware  systems.  The  algorithm  was  first  implemented  in  the 
GROVE  system  (Group  Outline  Viewing  Editor)  described  in  Ellis  et  al.,  1990  and  1991.  Later,  the  method  of 
operational  transformation  has  been  improved  in  Nichols  et  al.  (1995);  Ressel  et  al.  (1996);  Sun  et  al.  (1998)  and  gun 
and  Ellis  (1998).Operational  transformation  prevents  lost  updatings  by  transforming  a  second  conflicting  updating  to 
another  type  of  updating  that  cannot  overwrite  the  first  updating.  'Die  GROVE  system  uses  a  conflict  matrix  that 
describes  how  each  type  of  conflict  in  text  updatings  inay  be  transformed.  By  using  operational  transformation  the  dirty 
read  anomaly  cannot  occur  either,  because  an  aborted  object  is  only  known  to  the  user  who  made  the  aborted  updating. 
After  a  compensatable  subtransaction  has  been  committed  globally,  operational  transformation  may  be  used  to  upgrade 
automatically  other  compensatable  subtransactions  to  the  new  version  of  the  object.  Other  upgrading  techniques  are 
described  in  e.g.  Neuwirth  et  al.  (1992). Operational  transformation  does  not  deal  with  the  non-repeatable  read  anomaly. 
Therefore,  other  countermeasures  may  be  used  to  prevent  these  anomalies  (see  e.g.  subsection  3.6). 

3.4  The  Linearization  Protocol 

Linearization  (Herlihy  and  Wing,  1990,  and  Pacull  and  Sandoz,  1993)  is  both  a  commit  and  an  isolation  protocol. 
The  main  idea  of  the  protocol  is  that  the  possibility  to  read,  update  or  annotate  the  central  copy  of  a  document  is  passed 
along  from  one  to  another  on  requests.  When  a  user  has  hisdier  turn,  it  is  possible  to  read  new  updated  versions  of 
requested  central  copy  objects,  and/or  it  is  possible  to  overwrite  the  central  copies  of  the  objects  with  the  user’s 
modified  object  versions.  In  the  main  version  of  this  protocol  the  user  only  uses  short  duration  locks. 
By  integrating  the  reread  countermeasure  it  is  possible  to  prevent  lost  updatings.  If  another  user  has  changed  the  central 
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copy  of  an  object,  it  should  be  possible  to  upgrade  updatings  to  the  new  version.  Tlie  dirty  read  anomaly  cannot  occur. 
The  problems  of  the  non-repeatable  read  anomaly  may  be  prevented  by  rereading  and  control  of  all  the  data  that  has 
been  changed  since  the  last  time  the  user  had  exclusive  update  rights.  If  this  is  done,  the  protocol  may  produce 
serializable  executions.  However,  this  is  not  realistic,  and,  therefore,  it  is  also  important  to  integrate  countermeasures 
against  the  non-repeatable  read  anomaly-in  the  protocol.  This  protocol  may  be  integrated  in  our  transaction  model  in  the 
following  way:  At  first,  new  updatings  are  executed  at  the  location  of  the  updating  user  as  compensatable  updatings. 
Later,  when  the  user  has  access  to  the  primary  copy,  the  pivot  subtransaction  is  executed.  Finally,  the  copies  of  the  other 
users  are  updated  by  using  retriable  subtransactions.  Altogether,  we  evaluate  the  Linearization  Protocol  and  its 
possibilities  for  integration  with  other  isolation  countermeasures  to  be  good.  In  our  View,  the  main  problem  of  this 
protocol  is  how  to  pt  the  users  to  collaborate  in  such  a  way  that  they  do  not  spoil  each  other’s  updatings,  when  they 
have  the  updating  rights.  In  DUPLEX  (Pacull  et  al.,  1994),  an  implementation  of  the  Linearization  Protocol  has  solved 
the  problem  in  the  following  way: 

•  The  document  is  decomposed  into  independently  editable  parts. 

•  The  decomposition  is  dynamic  and  based  on  document  structure;  it  reflects  both  document  state  and  each  author’s 

current  responsibility  and  involvement  on  different  parts. 

•  ■  Authors  are  allowed  to  choose  the  type  of  control  (exclusive,  pessimistic,  optimistic,  etc.,)  that  they  wish  on  the 

document  parts  they  are  concerned  with. 

We  believe  that  these  rules  are  very  important  in  order  to  manage  most  asynchronous  groupware  systems  in  a 
consistent  way.  Therefore,  we  recommend  integrating  these  rules,  into  the  previous  described  asynchronous  protocols 
wherever  it  is  possible. 

3.5  The  Read  Uncommitted  Protocol 

In  this  protocol  we  will  use  our  transaction  model  in  the  following  way:  At  first,  new  updatings  are  executed  at  the 
location  of  the  updating  user  as  compensatable  updatings.  Later,  a  pivot  subtransaction  updates  the  corresponding 
primary  copy,  and  if  the  primary  copy  is  changed  by  another  user,  the  pivot  updatings  are  rejected  and  compensated  in 
the  location  of  the  updating  user.  The  primary  copy  of  the  database  is  used  to  serialize  the  updating  transactions  in  order 
to  prevent  the  lost  update  anomaly.  However,  this  protocols  accept  both  the  dirty  read  anomaly  and  the  non-repeatable 
read  anomaly,  'ae  reason  is  that  in  CSCW  systems  with  shared  data  it  may  be  best  to  have  access  to  ’’dirty”  and  “non- 
repeatable  read”  data  as  early  as  possible,  because  the  alternative  only  allows  access  to  “old  information”,  and  old 
information  may  be  very  old  if  the  updating  transactions  are  long-lived.  This  protocol  has  very  poor  write  availability  if 
different  long-lived  transactions  want  to  update  the  same  data.  The  protocol  almost  corresponds  to  the  “read 
uncommitted”  isolation  level  (ANSI,  1992),  where  write  locks  do  not  exclude  reading  transactions.  However,  the  ANSI 
protocol  does  not  deal  with  primary  and  secondary  copies.  The  protocol  has  resemblance  to  the  commit/isolation 
protocol  of  the  SEPIA  hypertext  authoring  system  described  in  Haake  and  Wilson  (1992),  because  this  system  uses  the 
real  “read  uncommitted”  isolation  level  of  the  relational  DBMS  SYBASE.  The  main  difference  is  that  the  users  of 
SEPIA  do  not  have  their  own  database  copy,  but  this  is  not  a  major  difference  when  the  users  normally  can  read  what 
they  want  as  write  locks  do  not  exclude  readings.  By  using  SEPIA  it  is  possible  to  use  the  “SEPIA  Activity  Spaces”  for 
content,  planning,  argumentation,  etc.  as  countermeasures  against  the  other  consistency  problems. 

3.6  The  Group  Awareness  Countermeasure 

The  group  awareness  interaction  and  cooperation  rules  suggested  in  Koch  (1995)  may  prevent  the  dirty  read 
anomaly  and  the  non-repeatable  read  anomaly.  However,  group  awareness  may  also  have  more  social  and  innovative 
purposes  than  countermeasures  against  consistency  problems. 

In  tightly  coupled^  WYSIWIS  systems  (e.g.  Haake  and  Wilson,  1992),  where  the  users  share  the  same  view,  an 
additional  communication  channel  (e.g.  audio/video  links)  is  almost  necessary  in  order  to  prevent  consistency  problems. 
In  some  situations  Greenberg  and  Marwood  (1994)  recommend  using  the  additional  communication  channel  to  both 
prevent  lost  updatings  and  if  a  warning  comes  too  late  the  additional  channel  may  be  used  to  repair  the  lost  data. 

4  Conclusions 

This  paper  has  illustrated  how  distributed  semantic  ACID  properties  can  be  implemented  in  distributed  CSCW 
systems  by  using  the  single  pivot  transaction  model  and  countermeasures  against  the  different  consistency  problems  that 
occur  when  only  semantic  ACID  properties  are  implemented. 

It  is  not  possible  to  select  one  protocol  as  the  best,  because  some  protocols  are  more  suitable  for  large  projects  and 
others  for  small  projects,  etc.  However,  our  analyzes  of  the  different  commiVisolation  protocols  have  illustrated  that 
countermeasures  against  lost  updatings,  and  the  rest  of  the  isolation  anomalies  may  be  integrated  in  such  a  way  that  it  is 
possible  to  tailor  commit/isolation  protocols  for  the  different  phases  of  a  given  project.  We  have  also  illustrated  that  it 
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may  be  important  to  use  a  common  transaction  model  for  all  the  commit/isolation  protocols  supported  by  a  CSCW 
software  product,  because  this  model  allows  the  upgrade-  and  back  out  tools  for  transactions  to  be  designed  in  such  a 
way  that  they  can  accept  changes  in  the  commit/isolation  protocol  used  in  the  different  phases  of  a  CSCW  project. 
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Abstract.  Spatial  data  models  have  been  extensively  studied  during  the  last  decade.  However,  require¬ 
ments  of  a  spatial  database  system  regardless  of  any  specific  application,  have  not  yet  received  much 
attention. 

In  this  paper,  a  general  Object-Oriented  spatial  data  model  is  introduced.  This  model  considers  a  spatial 
database  system  in  general,  without  focusing  on  specific  features  or  applications,  and  presents  a  new 
classification  method  for  spatial  objects  into  maps.  The  concept  of  map  as  defined  here,  is  an  appropriate 
definition  for  objects  with  arbitrary  set  of  spatial  components.  This  concept  is  similar  to  the  one  of  a  map 
in  the  real  world.  Map  definition  is  followed  by  the  definition  of  map  hierarchy  and  operations  on  maps 
which  can  be  used  to  answer  queries  that  might  be  too  complicated  otherwise. 


1  Introduction 


On  the  threshold  of  21st  century,  topics  such  as  urban  planning,  land  use,  city  and  road  planning  and  car 
navigation  have  received  much  attention.  The  spatial  data  related  to  these  applications  have  specific  features, 
such  as  high  volume  and  complex  structure.  Modeling  spatial  data  is  a  basic  step  in  designing  a  spatial  database 
system. 

Research  which  has  been  carried  out  so  far,  mostly  consider  specific  features  of  a  spatial  database  system  [7, 
12],  or  discuss  spatial  data  modeling  from  the  point  of  view  of  a  specific  application  [3].  Furthermore,  most  of  the 
database  systems  which  have  been  designed  for  spatial  purposes  have  been  built  above  the  relational  approach[10, 
11].  However,  relational  approach  is  not  powerful  enough  to  be  used  as  the  basis  for  spatial  database  systems. 

A  recent  approach  is  to  build  a  spatial  database  system  around  an  Object-Oriented  paradigm  [14, 4, 16, 13, 
5,8].  Object-Oriented  benefits  comply  with  the  requirements  of  spatial  systems. 

Spatial  objects  have  always  been  considered  as  individual  objects  in  the  literature,  and  the  only  categorization 
which  has  been  considered  is  the  classification  of  objects  with  the  same  structure  into  classes.  Furthermore,  in 
order  to  avoid  complex  operations,  it  has  always  been  assumed  that  a  spatial  object  has  only  one  geometric 
attribute.  Therefore,  arbitrary  categorization  of  spatial  (geometric)  properties  has  received  no  attention. 

This  paper  presents  an  Object-Oriented  spatial  data  model  which  considers  a  spatial  database  system  in 
general  without  considering  any  particular  features  or  requirements  of  an  specific  application.  It  introduces 
the  concept  of  the  map  as  an  arbitrary  class  of  spatial  objects  and  defines  various  operations  on  maps.  The 
categorization  of  objects  into  maps  allows  us  to  create  a  structure  of  data  in  an  efficient  hierarchical  way,  define 
operations  such  as  Join  and  Zoom  on  maps  which  have  significant  effect  on  the  usability  of  the  database  system 
and  replying  a  wide  range  of  queries.  The  benefits  of  Object-Oriented  paradigm  provide  high  flexibility  for  the 
data  model.  Therefore,  new  features  can  be  added  to  the  model.  Furthermore,  the  data  model  is  general  enough 
to  be  used  as  the  basis  for  a  multipurpose  spatial  database  system. 

In  the  presented  data  model,  the  representation  and  manipulation  of  data  is  based  on  Frame  logic  (F-logic) 
[9].  Since  F-logic  features  are  not  sufficient  for  our  purpose,  additional  features  have  been  introduced  where 
necessary. 

This  paper  is  divided  into  6  sections.  The  following  section  introduces  the  spatial  data  types  and  their  related 
operations.  Section  3  explains  new  feature  that  has  been  added  to  the  logic  and  its  interaction  with  already 
existing  features.  In  section  4  we  introduce  the  concept  of  map  and  the  partial  order  between  maps.  Operations 
on  maps  are  given  in  section  5.  Section  6  summarizes  and  concludes  the  paper. 
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2  Data  types  and  Operations 

Objects^  in  a  spatial  database  system  have  geometric  and  descriptive(non-geometric)  attributes.  Descriptive 
attributes  might  be  numbers,  character  strings  or  booleans.  Various  types  of  geometric  attributes  have  been 
defined  in  the  literature[7, 14].  We  employ  the  main  types  point,  line  and  region. 

The  smallest  definable  geometric  attribute  is  a  point  which  can  be  represented  by  its  coordinates  in  the 
Euclidean  plane.  ^  Given  two  distinct  points  pi  and  p2,  a  line  segment  is  defined  which  connects  the  two 
points.  A  connected  graph  consisting  of  a  set  of  line  segments  is  defined  as  a  line.  A  region  is  defined  by  the 
definition  of  its  border  line. 

We  assume  that  a  geometric  object  is  an  object  with  only  one  geometric  attribute.  This  assumption  simplifies 
the  definition  of  geometric  operations.  For  more  complicated  cases  where  various  geometric  attributes  have  to 
be  assumed,  the  concept  of  map  will  be  considered. 

A  geometric  object  is  defined  as  follows: 

Definition  1.  An  object  is  a  Geo  — Object  if  it  has  one  and  only  one  geometric  attribute  from  types  point,  line 
or  region. 

Various  operations  on  geometric  data  have  been  defined  in  the  literature  [14,7].  We  have  defined  a  set  of 
spatial  operations.  However  since  the  whole  set  of  operations  does  not  fit  into  the  limits  of  this  paper,  only  the 
Adjacency  operation  is  introduced  here.  ^ 

Predicate  Adjacent{\\)  specifies  if  two  Geo-Objects  are  adjacent.  We  define  Adjacency  for  two  points,  two 
lines,  two  regions  or  one  line  and  one  region. 

Definition  2.  Letpi{xi,yi)  and p2{x2,y2)  be  two  Points.  pi  ||  P2  iff 

(I  xi -xa  |<  e)  A  (I  2/1 -y2  |<e), 

where  e  is  the  minimum  possible  distance  between  two  Points. 

Definitions.  Let  01  and  02  be  two  Lines,  01  \\  02  iff 

(01  not  Intersects  02)  A  (3pl  :  Point  On  01  A  3p2  :  Point  On  02  such  that  pi  \\  p2) 

Definition  4.  Let  01  be  a  Geo-Object  of  type  Line  and  02  be  a  Geo- Object  of  type  Reaion 
01\\02iff01\\Border(02). 


Definition  5.  Let  01  and  02  be  two  Geo-Objects  from  type  Region,  01  ||  02  iff 
Border{Ol)  |j  Border{02). 

3  The  logic 


F-logic  has  been  used  as  the  logical  basis  for  our  data  model.  F-logic  is  a  formalism  for  defining,  querying  and 
manipulating  database  schema[9].  . 

Hierarchy  of  classes  and  individual  objects  in  F-logic,  is  represented  by  an  IS-A  hierarchy,  which  might  be  a  class 
membership  or  a  subclass  relationship.  For  example  Tokyo  is  a  member  of  the  object  class  City  and  Student  is 
a  subclass  of  the  object  class  Person. 

Since  IS-A  hierarchy  is  not  sufficient  for  defining  the  relationship  between  objects  in  a  spatial  data  model 
we  propose  an  expansion  of  F-logic  whereby  the  PART-OF  hierarchy  is  added  to  the  logic.  To  date,  many 
Object-Oriented  data  models  have  been  designed  with  the  purpose  of  capturing  more  of  the  meaning  of  an 
application  environment [6, 1]).  However,  the  concept  of  PART-OF  hierarchy  has  not  been  considered  by  these 
data  models. 

Figure  1  displays  a  simple  example  of  a  spatial  data  model.  The  hierarchy  of  objects  in  this  figure  is  expressed 
by  PART-OF  relationship. 

'im  ^  object  and  its  attributes  is  considered  in  the  same  way  as  objects  in  Object-Oriented  programming 

3  concept  of  elevation  will  not  be  considered  in  this  paper,  therefore  two  dimensional  space  suffices  our  needs 
The  full  set  of  operations  will  be  included  in  the  full  paper. 
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Country 


Prefecture  (State) 


Museum  River  Street  Hospital  School 


Fig.  1.  A  sample  spatial  data  model 


3.1  PART-OF  relationship 

Part-whole  relationship  has  already  been  studied  in  detail[2, 15].  We  study  this  relationship  from  the  point  of 

view  of  a  spatial  data  model.  PART-OF  relationship  between  Geo-Objects  is  defined  as  follows: 

Definition  6.  Let  Oi  and  O2  be  Geo-Objects  with  Ri  and  R2  as  their  geometric  attributes, 

Oi  PART-OF  O2  iff  Ri  CR2. 

We  recognize  four  various  interpretations  for  PART-OF  relationship: 

-  We  say  object  Oi  is  a  WRP  -  PART  -  OF(whole  requires  part)  part  of  object  O2  if  Oi  is  an  inseparable 
requirement  for  O2  and  O2  can  not  exist  without  Oi  (Water-Storage  is  WRP  -  PART  -OF  City). 

-  Object  Oi  is  a  PRW  -  PART  -  OF(part  requires  whole)  part  of  object  O2  if  Oi  can  not  exist  without 
being  part  of  O2  (a  Movie-Theater  is  PRW  -  PART  -  OF  City). 

-  A  PART  -  OF  relationship  is  called  strong  S  -  PART  -  OF  ii  it  is  WRP  -  PART  ~  OF  and  PRW  - 
PART  —  OF  (City-Government  is  5  —  PART  —  OF  City). 

-  A  PART  -  OF  relationship  is  called  weak  W  -  PART  -  OF  if  it  is  neither  WRP  -  PART  -  OF  nor 
PRW  -  FART  -  OF  (Gold-Mine  is  W  -  FAFT  -  OF  City). 

3.2  IS-A,  PART-OF  interrelationship 

Figure  2  represents  the  general  form  of  interrelationship  between  IS-A  and  PART-OF  relationships.  However 

this  interrelationship  does  not  hold  for  all  types  of  PART-OF. 


PART-OF 


IS-A 

p - ^ 

PART-OF 

Fig.  2.  IS-A,  PART-OF  interrelationship 


The  following  cases  of  interrelationship  between  IS-A  and  PART-OF  relationships  can  be  derived  from  Figure 
2.  In  what  follows  represents  class  membership  and  denotes  subclass  relationship. 

1.  Vg,  s,  r,  If  (r  ::  s  V  r  :  s)  A  (g  WRP  -  PART  -  OF  s),then 

3  p  ((p  ::  g  V  p  ;  g)  A  (p  WRF  -  PART  -  OF  r))  .  ^ 

2.  Vp,  g,  s,  If  (p  ::  g  V  p  :  g)  A  {q  PRW  -  PART  -  OF  then 

3  r  (  (r  ::  s  V  r  :  s)  A  (p  PRW -PART -OF  r)). 

3.  Cases  1  and  2  also  hold  for  strong  part  of  (S  -  PART  —  OF). 
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4  Object  Categorization 

Defining  geometric  objects  and  relationships  IS-A  and  PART-OF,  result  in  categorization  of  objects.  Object 
Country,  for  instance,  can  be  defined  as  a  whole  having  objects  City,  River,  Road,  Lake,  Sea  and  Mountain  as 
its  parts.  The  PART-OF  hierarchy,  arranges  the  above  set  of  objects  in  a  hierarchical  category. 

A  map  is  defined  as  a  type  of  object  which  may  have  other  objects  as  its  components.  A  map  may  as  well 
have  descriptive  attributes.  For  example,  map  of  a  country  can  have  attribute  ’name’  to  represent  the  name  of 
the  country. 

Definition  7.  A  map  is  an  object  with  a  set  of  Geo-Objects  or  maps  as  its  geometric  components. 

By  recursive  definition  of  maps,  we  can  create  higher  levels  of  hierarchy.  The  relationship  between  a  map 
and  its  object  components  is  a  PART-OF,  however  a  map  is  corresponded  to  its  simple  attributes^  by  €  sign. 
For  example  (Hospital  PART-OF  city)  and  (population  £  city). 


4.1  Partial  Order  of  maps 

The  set  of  all  maps,  M  is  partially  ordered  and  the  relation  <  is  defined  based  on  the  information  which  can  be 
retrieved  from  each  map. 

The  concept  of  equality  of  maps  can  be  defined  as  follows: 


Definition  8.  Let  mi  and  m2  be  maps,  P,0,0’  be  Geo-Objects  or  maps  and  D,D’  be  attributes 
mi  =  m2  iff 

VD,  (D  G  mi  D  £  m2)  A  (VO  PART  -  OF  mi  ,  30'  PART  -  OF  m2  A 

VO'  PART  -  OF  m2  , 30  PART  -  OF  mi)  such  that 

'iP,{P  PART-OF  O  ^P  PART-OF  0')A\/D',{D' e  O  ^  D' £  O') 

The  partial  order  <  means  that  the  maps  present  different  hierarchies  of  the  data  and  some  are  more  detailed 
than  others:  Map  m2  is  more  detailed  than  map  mi  (mi  <  m2),  if  it  contains  the  same  objects  of  mi  and  some 
other  objects  which  axe  PARTs-OF  objects  in  mi . 

Definition  9,  Let  mi  and  m2  be  maps,  P,P’,0,0’  be  Geo-Objects  or  maps  and  D,D’ be  attributes 
mi  <  m2  iff 

VD,  {D  £  mi  D  £  m2)  A  'iO,if  0  PART  —  OF  mi  then30'  PART  —  OF  m2  such  that 
VP,  (P  PART  -OF  O  =^P  PART  -  OF  0')A  VD',  (O'  £  O  ^  D'  e  0')A 
3P'  PART  -  OF  O'  such  that  P'  -^PART  -OF  O 

Figure  3  displays  partial  order<  between  maps. 


ml 


m2 


m3 


Fig.  3.  Partial  ordering  of  maps  (ml  <  m2  <  m3) 


5  Operations  on  maps 

After  the  concept  of  map  is  defined,  operations  can  be  introduced  to  manipulate  maps.  Some  of  the  operations 
which  have  been  already  defined  on  objects  can  be  expanded  to  maps  and  some  new  operations  can  be  introduced 
as  well.  A  set  of  map  operations  has  been  formally  defined  and  will  appear  in  the  ftill  paper.  Zoom  and  Join 
operations  will  be  discussed  here  in  brief. 

^  By  a  simple  attribute  we  mean  an  attribute  that  is  not  an  object 
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-  Join  operation  joins  two  maps  mi  and  m2  and  creates  a  single  map  m  which  contains  all  of  the  components 
of  mi  and  m2.  It  is  required  for  the  two  maps  to  be  adjacent.  The  operation  may  accept  specific  conditions 
to  determine  if  adjacent  objects  from  the  same  type,  must  be  unified  into  one  object  or  can  remain  as 
separate  objects. 

Definition  10.  (Map  Join):  Let  Mi  be  a  map  consisted  of  objects  0i,02,  -.,0„  having  types  Ti,T2, 
and  M2  be  a  map  consisted  of  objects  Oj,  O2)  having  types  Tl^T^,  —■T'f. 
and  30i{l  <i  <n)  and  30j(l  <j<k)  such  that: 

Oi  and  O'j  are  from  the  same  type  (Ti  —  TjJ  and  Oi  \\  O), 

The  unconditional  Join  of  maps  Mi  and  M2  is  the  map  M  consisted  of  all  of  the  objects  Oi,..., 

The  conditional  Join  of  two  maps  Mi  and  M2  is  the  map  Me  consisted  of  objects 

Oi, Oi-i,Oi+i, ...,  On,  O'l, Oj_i,Oj_^.i,  ...,0/^,0 

where,  O  =  Oi  U  O) 

For  instance,  two  maps  West-Germany  and  East-Germany  can  be  joined  into  one  map  called  Germany.  If 
no  conditions  are  considered,  city  objects  West-Berlin  and  East-Berlin  will  remain  as  separate  objects  in 
the  new  map,  however  by  the  condition  to  join  the  two  country  maps  over  the  two  city  objects,  they  will 
also  be  joined  into  one  city.  Figure  4  displays  an  example  of  Join. 


ml  iT^ 


Fig.  4.  Join  maps  ml  and  m2 


We  define  zooming  operation  on  maps,  based  on  our  definition  of  partial  order  of  maps. 

Since  maps  can  be  recursively  defined,  a  map  can  be  consisted  of  other  maps.  Zooming  a  map  On  one  of  its 
components  will  return  as  a  result  the  next  detailed  level  of  that  component  from  the  hierarchy  of  partial 
order.  The  zoom  can  be  continued  until  the  last(most  detailed)  level  of  hierarchy  has  reached. 

Definition  11.  (Zoom):  Let  Mi  he  a  map  consisted  of  objects  Oi,  O2,  ••.,  On  o,nd  M2  he  a  map  consisted  of 
objects  0'i,02,  —jO'n  such  that  Mi  <  M2  and  let  each  Oj  be  consisted  of  objects  Pii,...,Pik  ,  zooming  map 
Ml  on  Oi  will  return  the  components  of  0\  from  map  M2  ■ 

Figure  5  illustrates  zoom  operation.  Only  part  O^  from  map  M2  is  displayed  in  the  figure. 
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6  Conclusion 

In  this  paper,  a  general  Object-Oriented  spatial  data  model  was  presented  that  has  the  potential  to  model 
various  types  of  data  related  to  a  spatial  database  system.  F-logic  was  used  as  the  logical  basis  for  the  data 
model  and  new  features  were  added  to  the  logic.  Object  hierarchy  PART-OF  and  the  interrelationship  between 
PART-OF  and  IS-A  hierarchies  were  defined. 

Considering  geometric  objects  with  more  than  one  geometric  attributes  has  drawbacks  such  as  complicated 
process  and  flat(non  hierarchical)  structure  of  objects.  Therefore,  we  assumed  that  a  geometric  object  has  only 
one  geometric  attribute  and  defined  the  concept  of  map  for  arbitrary  classification  of  objects  with  geometric 
attributes  of  various  types.  Definition  of  map  and  PART-OF  relationship  between  maps  create  a  hierarchy  of 
data  similar  to  the  hierarchy  between  objects  in  the  real  world.  This  hierarchy  is  introduced  as  partial  order. 
Another  benefit  of  using  maps  is  the  possibility  to  reuse  basic  geometric  objects  in  forming  maps. 

Various  operations  on  maps  were  defined.  Partial  order  between  maps  provides  the  basis  for  a  formal  defi¬ 
nition  for  zooming  process.  Zoom  is  one  of  the  specific  and  crucial  features  of  a  spatial  database  system  which 
up  to  now  has  not  been  formally  defined  and  has  been  considered  as  an  implementation  task.  However,  intro¬ 
ducing  a  formalism  for  zooming  in  modeling  phase  enables  us  to  design  the  zooming  process  and  determine  the 
portion  of  data  that  should  be  displayed  in  every  step  of  zooming.  Data  security  in  spatial  database  systems 
is  a  very  important  concern.  To  build  a  secure  spatial  database  system,  data  must  be  carefully  structured  in  a 
hierarchical  way.  The  formalisms  presented  in  this  paper  for  map  hierarchy,  partial  order  and  zoom  operation 
are  rich  enough  to  handle  data  security  matters.  < 

Other  operations  were  defined  that  can  be  used  to  extract  complex  combinations  of  data  from  maps  or  even 
construct  new  maps.  Map  operations  are  applied  on  maps  and  act  on  the  map  and  its  components  at  the  same 
time.  In  another  words,  an  operation  on  a  map  can  be  automatically  inherited  by  its  components  and  it  does 
not  have  to  be  applied  on  each  component  separately.  The  designed  data  model  is  a  rich  collection  of  database 
formalisms,  conventions  and  operations. 
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Twin  -  A  Design  Pattern  for  Modeling  Multiple  Inheritance 
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Abstract.  We  introduce  an  object-oriented  design  pattern  called  Twin  that  allows  us  to  model  multiple  inheritance  in 
programming  languages  that  do  not  support  this  feature  (e.g,  Java,  Modula-3,  Oberon-2).  The  pattern  avoids  many  of 
the  problems  of  multiple  inheritance  while  keeping  most  of  its  benefits.  The  structure  of  this  paper  corresponds  to  the 
form  of  the  design  pattern  catalogue  in  [GHJV95]. 


1  Motivation 


Design  patterns  are  schematic  solutions  to  recurring  software  design  problems.  They  encapsulate  a  designer’s 
experience  and  makes  it  reusable  in  similar  contexts.  Recently,  a  great  number  of  design  patterns  has  been  discovered 
and  published  ([GHJV95],  [Pree95],  [BMRSS96]).  Some  of  them  are  directly  supported  in  a  programming  language 
(e.g.  the  Prototype  pattern  in  Self  or  the  Iterator  pattern  CLU),  some  are  not.  In  this  paper  we  describe  a  design  pattern, 
which  allows  a  programmer  to  simulate  multiple  inheritance  in  languages  which  do  not  support  this  feature  directly. 

Multiple  inheritance  allows  one  to  inherit  data  and  code  from  more  than  one  base  class.  It  is  a  controversial  feature 
that  is  claimed  to  be  indispensable  by  some  programmers,  but  also  blamed  for  problems  by  others,  since  it  can  lead  to 
name  clashes,  complexity  and  inefficiency.  In  most  cases,  software  architectures  become  cleaner  and  simpler  when 
multiple  inheritance  is  avoided,  but  there  are  also  situations  where  this  feature  is  really  needed.  In  such  situations,  one 
has  to  find  a  work-around  if  one  is  programming  in  a  language  that  does  not  support  multiple  inheritance  (e.g.  in  Java, 
Modula-3  or  Oberon-2).  The  Twin  pattern  —  introduced  in  this  paper  —  provides  a  standard  solution  for  such  cases.  It 
gives  one  most  of  the^benefits  of  multiple  inheritance  while  avoiding  many  of  its  problems. 

The  rest  of  this  paper  is  structured  according  to  the  pattern  catalogue  in  [GHJV95]  so  that  the  Twin  pattern  could  in 
principle  be  incorporated  into  this  catalogue. 


1.1  Example 

As  a  motivating  example  for  a  situation  that  requires  multiple  inheritance,  consider  a  computer  ball  game  consisting  of 
active  and  passive  game  objects.  The  active  objects  are  balls  that  move  across  the  screen  at  a  certain  speed.  The  passive 
objects  are  paddles,  walls  and  other  obstacles  that  are  either  fixed  at  a  certain  screen  position  or  can  be  moved  under  the 
control  of  the  user. 

The  design  of  such  a  game  is  shown  in  Fig.  1.  All  game  items  (paddles,  walls,  balls,  etc.)  are  derived  from  a 
common  base  class  Gameltem  from  which  they  inherit  methods  for  drawing  or  collision  checking.  Methods  such  as 
drawQ  and  intersectsQ  are  abstract  and  have  to  be  refined  in  subclasses.  checkQ  is  a  template  method,  i.e.  it  consists  of 
calls  to  abstract  methods  that  must  be  implemented  by  concrete  game  classes  later.  It  tests  if  an  item  intersects  with 
some  other  and  calls  the  other  item's  collideWithO  method  in  that  case.  In  addition  to  being  game  items,  active  objects 
(i.e.  balls)  are  also  derived  from  class  Thread.  All  threads  are  controlled  by  a  scheduler  using  preemptive  multi-tasking. 
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The  body  of  a  ball  thread  is  implemented  in  its  runQ  method.  When  a  ball  thread  is  running,  it  repeatedly  moves  and 
draws  the  ball.  If  the  user  clicks  on  a  ball,  the  ball  sends  itself 'a  suspendQ  message  to  stop  its  movement.  Clicking  on 
the  ball  again  sends  a  resumeQ  message  to  make  the  ball  moving  again. 

The  important  thing  about  this  example  is  that  balls  are  both  game  items  and  threads  (i.e.  they  are  compatible  with 
both).  They  can  be  linked  into  a  list  of  game  items,  for  example,  so  that  they  can  be  sent  drawQ  and  intersectsQ 
messages.  They  can  also  be  linked  into  a  list  of  threads  from  which  the  scheduler  selects  the  next  thread  to  run.  Thus, 
balls  have  to  be  compatible  with  both  base  classes.  This  is  a  typical  case  where  multiple  inheritance  is  useful. 

Languages  like  Java  don't  support  multiple  inheritance,  so  how  can  we  implement  this  design  in  Java?  In  Java,  a 
class  can  extend  only  one  base  class  but  it  can  implement  several  interfaces.  Let's  see,  if  we  can  get  along  with  multiple 
interface  inheritance  here.  Ball  could  extend  Thread  and  thus  inherit  the  code  of  suspendQ  and  resumeQ.  However,  it  is 
not  possible  to  treat  Gameltem  just  as  an  interface  because  Gameltem  is  not  fully  abstract.  It  has  a  method  checkQ, 
which  contains  code.  Ball  would  like  to  inherit  this  code  from  Gameltem  and  should  therefore  extend  it  as  well.  Ball 
really  has  to  extend  two  base  classes. 

This  is  the  place  where  the  Twin  pattern  comes  in.  The  basic  idea  is  as  follows:  Instead  of  having  a  single  class 
Ball  that  is  derived  from  both  Gameltem  and  Thread,  we  have  two  separate  classes  Ballltem  and  BallThread,  which  are 
derived  from  Gameltem  md  Thread,  respectively  (Fig.  2).  Ballltem  and  BallThread  sre  closely  coupled  via  fields  so 
that  we  can  view  them  as  a  Twin  object  having  two  ends:  The  Ballltem  end  is  compatible  with  Gameltem  and  can  be 
linked  into  a  list  of  game  items;  the  BallThread  end  is  compatible  with  Thread  and  can  be  linked  into  a  list  of  threads. 


Fig.  2.  The  class  Ball  from  Fig.l  was  split  into  two  classes,  which  make  up  a  twin  object 


Twin  objects  are  always  created  in  pairs.  When  the  scheduler  activates  a  BallThread  object  by  calling  its  method  runQ, 
the  object  moves  the  ball  by  sending  its  twin  the  messages  moveQ  and  drawQ.  On  the  other  hand,  when  the  user  clicks 
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on  a  ball  with  the  mouse,  the  BalUtem  object  reacts  to  the  click  and  sends  its  twin  the  messages  suspendQ  and  resumeQ 
as  appropriate. 

Using  only  single  inheritance,  we  have  obtained  most  of  the  benefits  of  multiple  inheritance:  Active  game  objects 
inherit  code  from  both  Gameltem  and  Thread.  They  are  also  compatible  with  both,  i.e.  they  can  be  treated  both  as  game 
items  {draw,  click)  and  as  threads  (run).  As  a  pleasant  side  effect,  we  have  avoided  a  major  problem  of  multiple 
inheritance,  namely  name  clashes.  If  Gameltem  and  Thread  haA  fields  or  methods  with  the  same  name,  they  would  be 
inherited  by  BalUtem  and  BallThread  independently.  No  name  clash  would  occur.  Similarly,  if  Gameltem  and  Thread 
had  a  common  base  class  B,  the  fields  and  methods  of  B  would  be  handed  down  to  BalUtem  and  to  BallThread 
separately — again  without  name  clashes. 

2  Applicability 

The  Twin  pattern  can  be  used 

•  to  simulate  multiple  inheritance  in  a  language  that  does  not  support  this  feature.  s 

•  to  avoid  certain  problems  of  multiple  inheritance  such  as  name  clashes. 


3  Structure 

The  typical  structure  of  multiple  inheritance  is  described  in  Fig.3. 


Fig.  3.  Typical  structure  of  multiple  inheritance 
It  can  be  replaced  by  the  Twin  pattern  structure  described  in  Fig.4. 


Fig.  4.  Typical  structure  of  the  Twin  pattern 


254 


Perspectives  of  System  Informatics’99 


4  Participants 

Parentl  {Gameltem)  and  Parent2  (Thread) 

•  The  classes  from  which  you  want  to  inherit. 

Childl  (Ballltem)  and  Child2  (BallThread) 

•  The  subclasses  oi  Parentl  and  Parentl.  They  are  mutually  linked  via  fields.  Each  subclass  may  override  methods 
inherited  from  its  parent.  New  methods  and  fields  are  usually  declared  just  in  one  of  the  subclasses  (e.g.  in  Childl). 


5  Collaborations 

•  Every  child  class  is  responsible  for  the  protocol  inherited  from  its  parent.  It  handles  messages  from  this  protocol  and 
forwards  other  messages  to  its  partner  class. 

•  Clients  of  the  twin  pattern  reference  one  of  the  twin  objects  directly  (e.g.  ballltem)  and  the  other  via  its  twin  field 
(e.g.  ballltem.twin). 

•  Clients  that  rely  on  the  protocols  of  Parentl  or  Parent2  communicate  with  objects  of  the  respective  child  class 
(Childl  or  Child2). 


6  Consequences 

Although  the  Twin  pattern  is  able  to  simulate  multiple  inheritance,  it  is  not  identical  to  it.  There  are  several  problems 
that  one  has  to  be  aware  of; 

1  Subclassing  the  Twin  pattern.  If  the  twin  pattern  should  again  be  subclassed,  it  is  often  sufficient  to  subclass  just  one 
of  the  partners,  for  example  Childl.  In  order  to  pass  the  interface  of  both  partner  classes  down  to  the  subclass,  it  is 
convenient  to  collect  the  methods  of  both  partners  in  one  class.  One  can  add  the  methods  of  Childl  also  to  Childl 
and  let  them  forward  requests  to  the  other  partner  (Fig.5). 


Fig.  S.  Childl. MIQ  forwards  the  message  to  Childl.  MIQ 

This  solution  has  the  problem  that  Sub  is  only  compatible  with  Childl  but  not  with  Childl.  If  one  wants  to  make  the 
subclass  compatible  with  both  Childl  and  Childl  one  has  to  model  it  according  to  the  Twin  pattern  again  (Fig.6). 
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MIO 


Parent2 


v2 


M20 
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ChUdl 


v3 


MIO 

M30 


twin 


H  Child2 


twin 


M20 


GrandChildl 

gtwin  ^  , 

GrandChild2 

^  gtwin 

M2() 

Fig.  6.  The  subclass  of  Child!  and  Child!  is  again  a  Twin  class 

2  More  than  two  parent  classes.  The  Twin  pattern  can  be  extended  to  more  than  two  parent  classes  in  a  straightforward 
way.  For  every  parent  class  there  must  be  a  child  class.  All  child  classes  have  to  be  mutually  linked  via  fields  (Fig.7). 


Fig.  7.  A  Twin  class  derived  from  three  parent  classes 

Although  this  is  considerably  more  complex  than  multiple  inheritance,  it  is  rare  that  a  class  inherits  from  more  than 
two  parent  classes. 

7  Implementation 

The  following  issues  should  be  considered  when  implementing  the  Twin  pattern: 

1  Data  abstraction.  The  partners  of  a  twin  class  have  to  cooperate  closely.  They  probably  have  to  access  each  others' 
private  fields  and  methods.  Most  languages  provide  features  to  do  that,  i.e.  to  let  related  classes  see  more  about  each 
other  than  foreign  classes.  In  Java,  one  can  put  the  partner  classes  into  a  common  package  and  implement  the  private 
fields  and  methods  with  the  package  visibility  attribute.  In  Modula-3  and  Oberon  one  can  put  the  partner  classes  into 
the  same  module  so  that  they  have  unrestricted  access  to  each  others'  components, 

2  Efficiency.  The  Twin  pattern  replaces  inheritance  relationships  by  composition.  This  requires  forwarding  of 
messages,  which  is  less  efficient  than  inheritance.  However,  multiple  inheritaiice  is  anyway  slightly  less  efficient 
than  single  inheritance  [Str89]  so  that  the  additional  run  time  costs  of  the  Twin  pattern  are  not  a  major  problem. 
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1  Introduction 

A  database  can  be  usually  seen  as  a  collection  of  records.  In  object  oriented  models  [6, 1]  records,  called  objects, 
have  a  special  field  and  may  have  other  additional  fields.  The  value  of  the  special  field  is  assumed  to  give 
a  unique  identification  of  the  object  in  a  context.  The  context  of  an  object  is  its  class  which  is  a  named 
collection  of  objects  with  the  same  type.  Other  additional  fields  of  records  are  methods.  Classes  are  organized 
in  an  inheritance  hierarchy.  In  the  absence  of  a  standard  formal  object  data  model,  various  models  have  been 
proposed  [7,5,2].  The  ODMG  group  carried  out  an  effort  of  standardization  and  proposed  an  object  data 
language  ODL,  and  an  object  query  language  OQL  [4].  However,  no  formal  model  has  emerged  with  the  same 
authority  as  the  relational  model.  In  this  paper  we  provide  a  formal  semantics  for  most  common  object  concepts 
in  different  existing  object  models.  In  doing  so,  we  follow  the  relational  database  tradition;  namely  the  clear 
separation  between  schema,  domain  and  instance.  We  consider  a  class  as  a  named  collection  of  partial  functions 
with  the  same  domain.  The  result  of  each  function  on  an  object  is  a  calculation  or  a  value  which  is  an  element 
of  some  type.  Type  expressions  are  obtained  from  basic  types  and  class  names,  using  two  constructors  set  and 
®.  However,  the  semantics  of  ®  in  this  paper  is  not  the  usual  cartesian  product  of  types  but  a  semantics  more 
suitable  for  dealing  with  partial  functions  and  null  values. 

2  The  Data  Model 

2.1  Database  Schema 

In  what  follows,  by  an  inheritance  relation  over  a  set  X,  we  mean  a  finite  binary  relation  which  is  irreflexive 
and  has  no  cycle.  Clearly  the  transitive  and  reflexive  closure  of  any  inheritance  relation  is  a  partial  order. 
An  inheritance  relation  is  represented  either  (1)  as  a  finite  subset  R  of  X  x  AT  or  (2)  as  a  set- valued  function 
R'.  X  'Pf{X),  where  Vf{X)  is  the  set  of  finite  subsets  of  X.  The  correspondence  between  the  two  representation 
is  X  Ry  y  e  R{x).  We  use  the  same  symbol,  say  R,  for  both  representations,  and  we  denote  by  R{x)  the 
elements  related  to  x  via  R.  Similarly,  we  consider  a  finite  ternary  relation  over  {X,Y,Z)  alternatively  (1)  as  a 
finite  subset  R  of  AC  x  y  x  .Z,  or  (2)  as  a  function  R:  X  RfiY  x  ■Z'). 

Definition  1  A  ternary  relation  R  over  iX,Y,  Z)  is  said  to  be  XY -functional  to  Z  if  it  satisfies  .•  Va;  e  X  Vj/  € 
Y  yz  E  Z '^z' £  Z  (R{x,y,z)  A  R{x,y,z')  z  =  z'). 

Let  A,  M  and  C  be  enumerable  non  empty  and  pairwise  disjoint  sets,  that  we  call  set  of  attribute  names,  method 
names,  and  class  names  respectively.  Let  (7  be  a  non  empty  finite  set  of  class  names,  and  fi  a  non  empty  finite 
set  of  type  names,  that  we  shall  call  basic.  We  assume  that  types  are  built  as  follows: 
rc::=/3\C\Tc®rc\  set  Tc 

Elements  of  Tc  are  called  object-types  (or  types  for  simplicity).  In  the  sequel,  Tq  will  denote  the  set  of  non 
empty  sequences  of  elements  of  Tc,  and  inheritance  relations  will  commonly  be  denoted  by  isa. 

Definition  2  We  say  S  =  {C,isa,att,meth)  is  an  object-oriented  database  schema  (or  a  schema  for  short)  if: 

-  C  is  a  finite  non  empty  subset  of  class  names, 

-  isa  is  an  inheritance  relation  over  C, 

-  att  is  a  finite  ternary  relation  over  iC,A,Tc),  which  is  C A- functional  toTc, 

-  meth  is  a  finite  ternary  relation  over  (C,M,T^),  which  is  CM- functional  to  T^  , 

such  that  for  every  c  in  C,  one  of  the  sets  isa(c),  att{c)  or  meth{c)  is  not  empty. 
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We  call  each  c  =  ic,isa{c),att{c),meth(c))  a  class  of  S  with  name  c,  each  {a,t)  in  att(c)  an  attribute  of  c 
with  name  a  and  type  t;  and  each  (m,  tit2  •••th)  in  meth{c)  a  method  of  c  with  name  m  and  profile  tit2  . .  -  tk- 
The  above  definition  implies  that  classes  of  a  schema  have  distinct  names.  Thus,  a  class  can  be  recognized 
by  its  name.  The  transitive  and  reflexive  closure  of  iso  is  denoted  by  <isa-  We  read  c  isa  c'  as  c  inherits  c' 
and  c  <isa  d  as  c  is  a  subclass  of  d.  The  functionality  of  att  and  meth  means  that  overloading  of  attributes 
or  methods  is  not  allowed  within  a  class,  but  allowed  in  distinct  classes.  Therefore,  in  the  whole  schema,  an 
attribute  (o, t)  or  a  method  {m,tit2--tk)  of  c  should  be  seen  as  {c,a,t)  or  {c.m,tit2-.tk)  respectively.  Single 
inheritance  as  well  as  multiple  inheritance  are  allow'ed.  Definition  2  says  that  if  a  class  has  no  attributes  and 
no  methods,  it  must  at  least  inherit  another  class,  and  if  a  class  does  not  inherit  any  other  class  and  has 
no  methods  (or  attributes)  it  must  have  at  least  one  attribute  (or  method).  Following  usual  notation,  we  shall 
denote  an  attribute  by  a  :  t  and  a  method  by  m  :  ti...tk-i  — tk,  or  by  m  : — >  t  (methods  without  parameters). 
The  standard  class  declaration  of  the  opposite  Fig- 


ure  correspond  in  our  setting  to 

class  c  inherit  ci . . . Cm 

isa{c)  ={ci,...,Cm} 

attributes  ; 

att(c)  ~  {(Oljfl))'-  -  )(ttn)^n)} 

Ql  .  J  ...  J  ttn  *  tn 

meth{c)  =  {{mi,tl...tlj,...,imp,t^...tlj} 

methods  : 

Thus,  a  finite  set  of  such  declarations  forms  a 

mi:  ti,... 

schema  iff  the  resulting  functions  isa,  att  and 

meth  satisfy  the  conditions  of  Definition  2.  Fig¬ 

ure  1  will  be  our  running  example  throughout  the 

^mp:  tl,...  ,tl^_i  -^tl^ 

paper. 

class  Pers 

class  Prof  inherit  Emp 

attributes  : 

attributes  : 

name :  string 

supervise  :  set  Stud 

ssn  :  int 

teaches  :  set  Course 

charge  :  set  Proj 

class  Proj 

class  Emp  inherit  Pers 

methods  : 

attributes  : 

attributes  : 

bonus :  int  —>■  int 

name  :  string 

charge  :  string 
hired-date  :  int 

budget  :  int 

salary  :  int 

class  Stud  inherit  Pers 

methods  : 

attributes  : 

class  Course 

bonus :  — >■  int 

supervisor  :  Prof 

attributes  : 

seniority :  int  int 

takes  :  set  Course 

name  :  string 
level  :  string^int 

class  Dir  inherit  Emp 
attributes  : 

preq  :  set  Course 

appoint-date  :  int 

class  Tutor  inherit  Stud,  Emp 

methods  : 

methods  : 

seniority :  int  — >  int 

bonus :  -4  int 

Fig.  1.  An  example  of  schema 


2.2  Inheritance  and  Overloading  Problem 

Mheritance  provides  a  mechanism  allowing  to  relate  together  properties  of  classes.  When  c  <isa  d,  each  object 
of  c  may  be  seen  as  an  object  of  d,  thus  properties  of  d  may  be  considered  also  as  properties  of  c.  But  this 
consideration  can  cause  a  name  conflict  in  c.  For  instance,  in  our  example,  the  attribute  charge  ;  string  in  Emp 
causes  name  conflict  with  charge  :  set  Proj  in  Prof.  A  similar  name  conflict  will  happen  for  methods  seniority 
in  Emp  and  seniority  in  Dir  although  they  have  the  same  type.  One  way  to  avoid  such  name  conflicts  is  to 
rename  inherited  attributes  or  inherited  methods  whenever  conflict  may  arise.  Since  our  next  discussion  will 
not  vary  if  we  talk  about  attributes  or  methods,  we  shall  do  the  discussion  for  attributes  only. 
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Definition  3  Let  c  and  Ci  be  two  classes  of  a  schema  of  S  such  that  c  <isa  cj.  We  say  (ci,ai,ti)  does  not 
conflict  with  the  class  c  if  for  every  attribute  (02,03,  *2)  ofS,  we  have  Ci  <isa  02  whenever  c  <isa  03  and  oi  =  03. 


In  our  example  attribute  charge  of  Emp  conflicts  with  Prof  but  does  not  conflict  with  Dir.  Similarly,  the 
method  seniority  of  Emp  conflicts  with  the  class  Dir.  Now,  we  can  express  our  renaming  procedure  as  follows : 

Renaming  procedure  :  For  every  class  c  and  every  superclass  ci  of  c,  if  a  property  (i.e.  attribute  or  method) 
p  of  Cl  conflicts  with  c  then  rename  p  in  c. 

Our  formal  way  for  renaming  will  be  prefixing.  In  practice,  instead  of  prefixing  names,  new  names  may  be 
introduced.  We  stress  that  the  renamed  attribut  has  the  same  type  as  the  original  one.  As  a  consequence,  our 
notion  of  inheritance  does  not  impose  any  covariance  or  contravariance  conditions.  This  is  in  contrast  to  the 
sub-typing  in  object  programming  languages  [1,3]. 

3  The  Type  System 

3.1  Concrete  Types 

Let  us  add  to  our  type  system  a  new  type  with  one  element,  called  unit.  Thus ; 
rc::=l3\  C  \T®T\setT,  T  "=  Tc  \  unit 

Each  basic  type  name  t  is  assumed  to  denote  a  set  ff|  of  values  that  we  will  call  concrete  type  of  t.  The  concrete 
type  of  each  class  name  is  supposed  to  be  a  special  enumerable  set  oid,  which  is  disjoint  from  all  other  basic 
concrete  types.  The  elements  of  oid  are  called  object  identities.  Now,  we  consider  a  symbol  ±  that  denotes  an 
element  outside  the  concrete  basic  types  and  the  concret  type  oid.  The  concrete  types  of  all  other  types  are 
defined  recursively  as  follows : 

-|umt|  =  {T},  -  {set  tj  =  Vfilt}) 

-  Ih  0*2!  =  (Pil  X  1^21)  +  ([fil  X  {unit})  +  (lunitj  x  pal) 

where  x  and  +  are  the  usual  cartesian  product  and  the  usual  cartesian  coproduct  of  sets.  Elements  of  pj  will 
serve  to  define  the  stored  part  of  a  da^tabase.  It  is  important  to  note  that  the  semantics  of  (g)  is  not  the  usual 
cartesian  product  semantics.  This  special  semantics  of  !g)  will  allow  us  to  deal  with  null  values  and  later  on  with 
partial  functions.  In  the  context  of  databases  the  special  symbol  ±  can  be  seen  as  the  value  null.  Another  role 
of  the  symbol  ±  is  to  express  the  undefinedness  of  functions.  If  we  denote  pjj.  =  p|  +  then  the  following 

theorem  relates  <S>  to  the  usual  cartesian  product : 

Theorem  1  For  all  types  ti  and  t2,  pilx  x  psjx  and  pi  <g>f2lx  are  isomorphic.  ■ 

3.2  Classes  as  Types 

In  any  type  system,  basic  and  user-defined  types  come  with  their  operations.  In  our  setting  if  5  =  (C,  isa,  att,  meth) 
is  a  database  schema  then  every  class  {c,isa{c),  att{a),meth{c))  can  be  seen  as  a  special  user-defined  type.  The 
name  c  of  the  class  is  the  name  and  also  a  sort  of  this  user-defined  type.  Operations  of  c  are : 

-  if  (c,  a,  t)  is  an  attribute  then  a :  c  ->  Hs  an  operation  over  c; 

-  if  c  <isa  c'  and  (c',a,  t)  is  an  attribute  that  does  not  conflict  with  c,  then  ai  c-^  t  is  an  inherited  operation 
over  c; 

-  if  c  <isa  c'  and  (c',  o,t)  is  an  attribute  which  conflicts  with  c,  then  (c')o:  c  ->■  t  is  a  renamed  operation  over 

-  if  (c,  m,ti . . .  tk)  is  a  method  then  m :  c  (g)  ti  (g  . . .  <S  tk-i  ->  tk  is  an  operation  over  c; 

-  if  c  <isa  c'  and  (c',  m,  ti...  tk-itk)  is  a  method  that  does  not  conflict  with  c  then  m :  c®ti®t2  ■ .  ■<^tk-i  ->  4 
is  an  inherited  operation  over  c; 

-  if  c  <isa  c'  and  ...tk-itk)  is  a  method  which  conflicts  with  c  then  the  renamed  method  (c')m:  c® 

*1  ®  t2 . . .  ®  tfc-i  ->•  tfc  is  an  operation  over  c; 

-  if  c  <isa  c'  then  isa’^’’^  :  c -¥  c'  is  an  operation  over  c. 

Thus,  we  can  see  a  schema  as  a  set  of  type  specifications. 
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3.3  Functional  Terms 


In  an  object  data  model,  calculations  appear  in  two  ways.  On  the  one  hand  they  serve  to  define  the  dynamic 
part  (i.e.  methods)  of  the  database,  and  on  the  other  hand  they  perform  arithmetique  computation.  In  our 
approach  each  calculation  is  a  term  of  an  algebra.  This  algebra  acts  on  partial  functions  and  is  defined  by  the 
following  rules ; 


Functional  terms  of  a  given  schema  are  outputs  of  these  rules  whenever  inputs  are  operations  of  the  schema  or 
operations  of  basic  types. 

Example  1  Suppose  int  and  string  are  basic  types,  and  add*  denotes  the  prefix  notation  of  the  usual  operation 
+.  The  following  are  functional  terms : 


-  name:  Stud  int,  name:  Prof  string,  {Emp)honus\  Prof  — >■  int 

-  <name,  supervisor.name> :  Stud  -»•  string  ®  string, 

-  <fst.{Emp)bonus,  <snd,  terMOO*  >  >.add*  ;  Prof  ®  int  — )■  int. 


4  The  Semantics 

4.1  Database  Instance 

We  see^  an  instance  of  a  database  as  a  finite  set  of  persistent  objects  and  a  code  for  each  method.  As  usual  an 
object  is  a  pair  (i,  v)  where  i  e  oid  and  t;  £  p].  According  to  our  recursive  construction  of  p],  such  a  value  may 
have  a  cornplex  structure.  Thus,  v  may  refer  itself  to  other  object  identities.  The  value  v  referring  to  an  object 
identity  j  is  an  indication  for  saying  that  the  type  expression  t  has  used  a  class  name  in  its  construction.  But, 
since  we  have  interpreted  every  class  name  by  the  same  set  oid,  we  are  now  unable  to  say  what  class  name  has 
caused  the  appearence  of  j  in  v.  However,  we  need  this  lost  information.  Indeed,  if  a  persistent  object  refers  to 
another  object  the  later  must  be  also  persistent. 

Definition  4  For  every  type  expression  t,  every  value  v  of  pj  and  every  class  name  c  of  the  schema  S,  the  set 
ref  (v  :  t,c)  is  defined  recursively  as  follows : 

-  ref{v  :t,c)~  0,  for  every  basic  type  t; 

-  ref{v  :  c'  ,c)  =  if  c'  ^  c  and  refiv  :  c,  c)  =  {n}; 

-  ref{v  :  set  t,  c)  =  ref{vx  :  t,  c)  U  . . .  U  re/(u„  :  t,  c),  where  n  =  {ni,...,v„}; 

-Tef{v:ti®t2,c)  —  ref{vi:ti,c)  U  ref  {v2  :  t2,c),  where  v  =  (vi, 02).  ■ 

The  set  ref(v  :  t,  c)  is  the  set  of  all  object  identities  which  appear  in  v  because  of  the  presence  of  c  somewhere 
in  the  type  expression  t. 

A  functional  term  e  :  h  t2  denotes  a  partial  function  e  :  pj  — ^  pa].  But  we  see  e  as  a  function 

PI  :  pi  I  y  palx  such  that  e{x)  -  ±  means  ”e  is  undefined  on  x”.  Note  that,  1  appears  only  in  the  codomain 
of|el. 

Definition  5  A  database  instance  over  a  schema  S  =  {C,isa,att,meth)  is  a  function  5  that  associates 

1.  with  every  class  name  c  of  C  a  finite  subset  d{c)  of  oid,  such  that: 

if  C  <Cisa  c'  then  S(c)  C  S(c'), 

-  if  c  and  d  have  no  common  subclass  and  no  common  superclass  then  d(c)  n  6{d)  =  0- 

2.  with  every  attribute  (c,  a,t),  a  finite  function  o5  :  [c|  — >  pT  such  that :  ’  , 

-  def(aj)  Cd{c), 

-  for  all  i  e  6(c)  and  d  £  C,  ref(al(i)  :  fid)  C  d{d); 

3.  with  every  method  (c,m,ti  ■  ■  -tk-itk)  of  S,  a  functional  term 
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In  this,  definition  each  class  name  is  seen  as  a  persistant  root.  There  is  an  explicit  distinction  between  stored 
and  computed  paii  of  the  database.  The  stored  part  is  defined  by  clauses  1  and  2  and  the  computed  part  by 
clause  3.  The  second  clause  of  Definition  6  implies  that:  a  persistent  object  cannot  refere  another  object  unless 
that  object  is  persistant.  This  is  actually  the  principle  of  persistence  seen  earlier.  The  first  clause  of  Definition 
6  requires  that  S{c)  C  S{c')  whenever  c  <isa  c'.  This  means  that :  the  semantics  of  inheritance  is  set  inclusion. 

4.2  Semantics  of  rules 

In  order  to  define  the  semantics  of  the  rules  we  recall  some  practical  notations : 

-  For  two  sets  Ti,  T2,  ■.  Ti  x.  T2 -¥  Ti  {i  =  1, 2)  denote  projections  and  inf^'^^ :  Ti  -4  Ti  +T2  coprojections. 

When  T2  =  {±}  we  write  de/^^ :  Ti  Ti  +  {±}  and  undef’^'^ :  {1}  ->■  Ti  +  {X}  instead  of  and 

-  For  fi\  A~^  Ai  {i  =  1,2),  the  function  <  /i,/2  >:  A  ^1  x  A2  is  defined  by  <  /i,/2  >  (x)  =  (/iC®), /2(a:)). 
Similarly  for  g* :  A*  ->■  A  (i  =  1, 2)  the  function  [31,52] :  Ai  +  A2  — >•  A  is  defined  by : 

[5ijS2]{aj)  =  if  (x  =  imy)  then  9i{y)  else  if  (x  =  in2z)  then  32(2)  ■ 

-  li  fi:  Ai  -¥  Bi  (i  =  1,2)  then  fi  +  f2-  Ai  +  A2  ->  Ai  +  A2  is  an  abbreviation  for  [inf o/i,inf^®'^  0/2]. 

-  For  every  set  T  the  function  ter:  T  {1}  is  the  unique  function  from  T  to  {X},  id:  T  -¥  T  is  the  identity 
function.  An  element  a  of  T  is  seen  as  a  function  a:  {X}  -4  T,  where  o(X)  =  a. 

Now,  we  define  the  semantics  of  the  rules  as  fellows': 

Iid*I  =  def  o  id  =  def  [/.3J  =  [[gj,  undef]  o  I/|  [</,  3>|  =<  |/|,  lgj> 

[/st]  = 

|ter*J  =  def  o  ter  |unde/*J  =  undef 

The  apparent  complexity  of  the  above  semantics  is  due  to  our  concern  for  treating  null  values  and  undefinedness 
rigorously. 

4.3  Semantics  of  functional  terms 

Functional  terms  are  obtained  recursively  from  a  schema  <S  using  rules.  The  basis  of  the  recursion  consists  of 
constants,  basic  type  and  class  operations. 

Semantics  of  basic  operations  :  In  our  type  system  a  binary  operation  of  a  basic  type  looks  like  op*  :  t^t  — > 
t.  Thus,  its  semantics  is  [op*|  :  p (E» t]  — >  p|x-  Since  the  semantics  o^t®t  is  pj  x  p|  +  {X}  x  p|  +  p]  x  {X}, 
one  of  the  two  arguments  of  [op*|  may  be  undefined  (i.e.  equal  to  X).  We  assume  that  the  result  of  |qp*]  is  X 
whenever  one  of  its  arguments  is  X.  Formally, 
lop*l  =  op+ 

where  op  :  p]  x  p|  — >•  p|  is  a  usual  binary  operation  on  p| . 

The  rest  of  the  semantics  will  be  generated  from  a  database  instance  J. 

Semantics  of  inheritance  relationships :  We  expressed  c  <isa  c'  syntactically  as  the  operation  :  c  -> 

c'  of  c  (Section  3.2).  According  to  Definition  6,  (5(c)'C  5{c').  This  inclusion  corresponds  to  a  partial  function 
isaf‘^  :  |c]  — >  [c'Jjl-  Therefore  we  define:  psa'’'^']  =  isa^’’^  . 

Semantics  of  attributes :  Attributes  of  a  class  act  on  objects  of  that  class,  in  the  following  sens : 

-  for  every  attribut  {c,a,t)  in  S,  |ap  =  of, 

-  for  all  classes  c,  c',  if  c  <,*0  c'  then  for  every  attribute  [d ,  a,  t)  which  does  not  conflict  with  c,  [o]'^  = 

psa‘=’‘='.al  (=  [|aj''',unde/]  o  psac,c'j)^ 

-  for  all  classes  c,  c',  if  c  Kua  d  then  for  every  attribute  {d,a,t)  which  conflicts  with  c,  I(c')ap  =  pso'^’^^'.o]. 

The  second  (third)  of  the  above  clauses  says:  the  semantics  of  a  as  an  inherited  (renamed)  attribute  of  c  is  the 
semantics  of  a  as  an  attribute  of  d  but  restricted  to  objects  in  c. 

Semantics  of  methods:  Contrary  to  attributes,  methods  operate  on  objects  according  to  the  designer’s/ 
user’s  choice  for  early  or  late  binding.  In  early  binding  a  method  operates  in  the  same  way  on  all  objects  of  a 
class,  but  in  late  binding  the  operation  on  an  object,  depends  on  the  way  that  the  object  is  shared  by  other 
classes.  The  following  semantics  of  methods  suit  only  for  early  binding. 

-  For  every  method  (c,  m,  ti . . .  4)  in  S,  fm|^  |mf  J. 
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-  For  all  classes  c,  o',  if  c  <isa  c'  then  for  every  method  (o',  which  does  not  conflict  with  c, 

|^|C  ^  f  (=  [Imp', unde/]  o  |isa='=']),  if  k-1 

\  I</stiso®’°',snd  >  .mj,  if  k  >  1 


-  For  all  classes  c,  c',  if  c  <isa  c'  then  for  every  method  (c',m,ti .  which  conflicts  with  c, 


|(c')mf  =1 


psa‘=’'^'.ml,  if 

l<fst.isa*^’‘^',snd  >  .m|,  if 


k  =  1 
k  >  1 


5  Concluding  remarks 

We  have  introduced  a  formal  object-oriented  data  model  with  partial  semantics.  We  have  considered  a  partial 
map  as  a  total  map  X  — >  Y  U  {±},  where  ±  is  supposed  to  be  outside  Y.  This  point  of  view  suits  better 
to  database  theory.  We  have  considered  a  database  as  a  set  of  partial  functions.  Each  function  represents  an 
attribute  or  a  method,  and  ±  represents  null  value  (or  value  undefined).  A  similar  aproach  have  been  proposed  in 
[8]  with  a  categorical  point  of  view,  but  without  considering  methods  and  binding  modes.  This  paper  investigates 
with  methods  and  static  binding.  We  have  endowed  the  type  system  with  an  algebra  of  functions  by  means 
of  rules.  These  rules  are  similar  (but,  not  equivalent)  to  those  presented  in  [2],  because  they  both  contain  a 
common  mathematical  structure.  But,  contrary  to  [2]  our  semantics  for  this  structure  is  the  universe  of  sets 
and  partial  maps.  For  this  reason  we  have  introduced  a  particular  semantics  for  0,  whereas  they  use  the  usual 
cartesian  product  x . 
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1  Motivation 

The  incentive  to  write  a  nested,  heterogeneous  container  in  surfaced  in  the  SuchThat  project  [11].  Therein 
we  are  working  on  the  implementation  of  a  SuchThat  compiler.  The  first  prototype’s  back-end  [14],  as  well  as 
many  of  the  other  components,  were  implemented  in  Scheme  [8].  One  of  Scheme’s  main  advantages  is  the 
powerful  list  data  structure,  which  can  hold  arbitrary  data  types^ .  This  allows  the  user  to  build  nested  lists, 
e.g.  to  represent  a  parse  tree  or  symbol  table. 

Our  current  focus  is  on  merging  Tecton  [7]  with  SuchThat.  Due  to  severe  performance  problems  with  our  first 
prototype  we  have  switched  to  C"*"^  as  implementation  language.  The  STL  provides  basic  containers  that  suit 
most  simple  needs  and  exhibit  very  good  runtime  behavior.  The  containers’  major  drawback  for  our  purposes 
is  the  inability  to  hold  objects  of  different  types  and  that  they  do  not  support  nesting. 

We  will  show  that  exploitation  of  C++’s  newest  technologies,  like  templates  and  run-time  type  information, 
(RTTI),  lead  to  a  powerful  data  structure  based  on  the  STL.  We  think  that  the  different  paradigms  of  generic, 
object  oriented  and  functional  programming,  which  often  are  seen  as  adversaries,  can  instead  complement  each 
other. 

2  Approaches 

We  observed  a  trade  off  between  syntactic  elegance  and  runtime  performance.  This  made  us  come  up  with  two 
fundamentally  distinct  approaches. 

The  first  one,  the  more  conservative,  relies  on  an  abstract  base  class  that  provides  polymorphic  behavior 
with  easy  to  use  parameterized  standard  elements.  The  nseq  class  uses  template  template  arguments  (see  [1], 
14.3.3)  for  maximal  flexibility. 

The  second  approach  builds  on  the  semantics  of  chameleon  objects  [12].  It  is  outperformed  by  the  first  one 
regarding  runtime  but  excels  in  usability. 


2.1  Specification  of  the  Problem 

We  informally  state  with  the  following  three  requirements  what  we  call  a  heterogeneous,  nested  sequenee  S. 

1.  Every  STL  sequence  container  should  be  applicable  as  underlying  implementation  container  of  S  (flexibility 
property). 

2.  S  should  be  able  to  hold  arbitrary  objects  (heterogeneity  property). 

3.  Any  nested  sequence  S  should  be  able  to  hold  other  nested  sequences  recursively  (nesting  property). 


2.2  Classical  Polymorphism 

The  well  established  way  in  to  provide  polymorphic  behavior  uses  inheritance.  The  heterogeneous  container 
holds  pointers  to  a  base  class  and  the  runtime  system  will  dispatch  methods  based  on  the  polymorphic 
type.  Our  base  class  BaseElem  declares  the  virtual  functions  BaseElem*  clone  ()  and  BaseElem*  create ()  to 
support  the  virtual  constructor  idiom  (see  [2],  20.5). 

Instead  of  letting  the  user  write  wrapper  objects  for  every  type  he  uses,  we  deliver  the  template  class  Elemo 
that  inherits  from  BaseElem.  The  signature  is  template  <class  valT>  class  Elem  :  public  BaseElem.  This 

^  Of  course,  this  holds  true  for  any  untyped  language. 
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wrapper  class  does  all  the  tedious  work  a  user  usually  has  to  do  on  his  own:  define  constructors  and  destructors, 
as  well  as  various  auxiliary  methods  (e.g.  I/O  functions).  She  must  only  instantiate  the  template  class.  This 
works  for  basic  types  and  classes,  e.g.  Elem<int>  i  or  Elem<string>  sC'test"). 

Let  us  examine  the  class  nseq,  which  should  fulfill  the  problem  specification  given  in  section  2.1.  The 
heterogeneity  property  can  be  obtained  by  keeping  pointers  to  the  base  class  BaseElem  in  the  sequence.  If  we 
want  to  comply  to  the  nesting  property,  nseq  must  be  derived  from  BaseElem  itself.  Furthermore,  in  order  to 
use  STL  containers,  nseq  must  also  be  a  subclass  of  such  a  container.  These  considerations  lead  to  this  signature 
of  a  nested  list: 

class  nlist  ;  public  list<BaseElem+>,  public  BaseElem 

flexibility  property,  because  the  implementation  container  is 
hard-coded.  You  cannot  provide  diflferent  containers,  as  the  class  nlist  is  a  subclass  of  the  STL  container 
mstantiation  list<BaseElem=f‘>.  To  gain  the  desired  additional  level  of  abstaction,  we  use  template  template 
arguments,  a  very  novel  C++  feature,  nseq  becomes  a  template  class,  whose  template  argument  is  a  container, 
which  IS  a  template  class  itself.  Therefore,  a  simple  template  would  not  suffice.  The  final  class  header  for  nseq 
reads:  ^ 

template  <template  <class  valT>  class  containerT> 
class  nseq  :  public  containerT<BaseElemH‘>,  public  BaseElem 
Ihe  clone  () -function  has  a  boolean  parameter  shallow,  which  is  of  importance  for  nested  sequences  only 
It_  controls  if  either  a  shallow  or  a  deep  copy  of  the  container  is  made.  A  shallow  copy  creates  a  new  container 
with  pointers  to  all  top-level  elements.  A  deep  copy  create^  a  new  container,  recusively  holding  copies  of  the 
containers  and  atoms  in  the  source  sequence. 

Working  with  our  nseq  class  is  quite  simple.  An  instance  of  a  nested  deque  is  created  with  nseq<deque> 
nd.  We  can  use  all  of  deque’s  member  functions  to  add  elements  to  our  container,  e.g.  nd. push  back  (new 
pem<int>(4711)).  The  sequence  can  be  walked  with  the  STL  container’s  iterators,  but  only  at  the  top-most 
level  You  can  recursively  descend  into  nesting  layers,  if  the  member  function  bool  is_atom()  returns  false 
which  is  the  case  for  elements  that  are  nested  sequences.  When  you  walk  a  nseq  and  want  to  operate  on  the 
elements,  you  have  to  perform  a  dynamic  cast  on  BaseElem.  The  following  code  example  shows  how  the  first 
level  of  a  nested  sequence  is  walked  with  the  container  provided  iterator  and  every  integer  entry  is  replaced  bv 
Its  square  power. 

for  (nseq<list>: : iterator  iter  =  nl.beginO);  iter  !=  nl.endO;  ++iter) 
if  (intp  =  dynamic_cast<Elem<int>*>(*iter)) 

*intp  =  intp->getValue()  *  intp->getValue() ; 

Figurel  compares  the  layout  of  nseq<vector>  and  vector<int>2.  It  shows  that  we  get  a  memory  overhead 
of  two  posters  (eight  bytes)  for  every  element,  regardless  of  the  wrapped  object’s  type.  The  first  one  points 
to  BaseElem.  This  indirection  is  needed  to  use  C++’s  polymorphic  mechanism.  The  second  pointer  holds  the 
address  of  the  element’s  virtual  table.  i-  unc 
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Figurel.  Layout  comparison  of  a  standard  STL  container  and  a  nested  sequence. 


2.3  Chameleon  Objects 

technique  for  providing  a  generic,  type-safe  wrapper  class  is  presented.  This  goal  is  achieved 
rough  the  unparameterized  class  Value.  Contrary  to  the  class  itself,  all  its  methods,  like  the  constructor 
and  a  set  of  overloaded  operators,  are  parametrized,  i.e.  template  functions.  Thus,  any  object  of  arbitrary 
type  can  be  assigned  to  a  Value  object  due  to  the  parameterized  assignment  operator  template<class  T>  T 
operator- (const  T&) .  In  turn,  a  Value  object  can  easily  be  reassigned  to  an  object  of  its  initial  type  because 

ot  the  parameterized  conversion  operator  teraplate<class  T>  T&  operator  T(). 

'  We  assume  that  sizeof(int)  =  4  and  sizeof(pointer)  =  4,  which  is  true  for  most  contemporary  32bit  architectures. 
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The  Value  class  guarantees  strict  type  safety  by  signaling  any  attempt  to  assign  a  Value  object  to  another 
object  of  incorrect  type  by  throwing  an  exception®.  To  achieve  this  functionality,  the  Value  class  keeps  all 
information  about  the  wrapped  object  in  a  private,  static  data  member  inside  a  member  function,  parameterized 
with  the  same  type. 

Since  all  used  data  types  are  known  at  compile  time,  the  compiler  can  instantiate  the  corresponding  methods 
and  data  objects.  In  fact,  for  every  data  type  used  in  conjunction  with  a  Value  object,  a  full  set  of  operators 
and  methods  is  instantiated  by  the  compiler.  The  type  checking  of  any  operation  concerning  a  Value  object 
is  performed  by  these  methods  at  run  time.  Because  of  their  ability  to  change  their  internal  type  at  any  time, 
Value  class  instances  are  called  chameleon  objects. 

Given  this  Value  class,  we  can  now  construct  heterogeneous  containers  based  on  the  standard  STL  con¬ 
tainers  by  instantiating  such  a  container  for  Value  with  list<Value>  polyCont.  Thereafter,  objects  of  arbi¬ 
trary  type  can  be  inserted  into  the  container,  e.g.  polyCont. push_back(12),  po lyCont. push JsackC 0.9)  and 
polyCont. pushJback(string("hello")).  Because,  as  stated  above.  Value  objects  can  hold  objects  of  any 
type,  even  containers  can  be  inserted  as  elements  into  a  Value  parameterized  container,  thus  obtaining  nested 
containers. 

The  extraction  of  elements  from  the  container  is  straightforward,  too.  If  we  know  the  the  desired  ele¬ 
ment’s  type,  we  can  simply  query  it.  Given  the  list  polyCont  from  the  previuos  example,  we  can  write  int 
i=polyCont.front()  to  get  the  first  element  of  the  list.  More  care  must  be’ taken  if  the  type  of  the  desired 
element  is  unknown.  Since  overloading  the  typeidO  operator  is  not  allowed  in  (see  [1],  13.5),  the  Value 
class  defines  a  method  typeldO,  which  returns  the  type  information  for  the  currently  wrapped  object.  With 
this  information  and  Value’s  parameterized  method  template<class  T>  T&  getValueO,  one  can  access  every 
element  of  the  nested,  polymorphic  container.  This  is  shown  in  the  following  sample  code: 

//  double  sin(double);  a  function  with  this  signature  must  exist 
void  apply (list<Value>  ftcont)  { 

for  (list<Value>:  ; iterator  it  =  cont.beginO;  it  !=  cont.endO;  ++it)  { 
if  (it->typeIdO  ==  typeid(list<Value>))  apply((list<Value>)H>it) ; 
else  if  (it->typeld()  ==  typeid(int))  *it  =  (int)*it  *  (int)*it; 
else  if  (it->typeIdO  ==  type  id  (double))  ♦it  =  sin(*it): 

> 

> 

3  Performance  Tests 

The  results  of  the  performance  tests  are  presented  in  Figure2.  We  compared  the  original  STL  list  and  vector 
containers  against  their  nested  counterparts  based  on  our  implementations.  The  tests  consisted  of  two  parts, 
container  creation  and  element  access.  They  were  all  performed  for  int  and  std: :  string  data  types.  The 
containers  were  filled  in  a  loop  using  push_back(T&) .  Access  was  measured  by  iterating  over  the  created  container 
and  mutating  its  elements. 

The  charts  show  the  overhead  introduced  by  our  containers  for  the  flat,  homogeneous  case,  where  of  course 
their  additional  features  are  not  used.  The  price  you  have  to  pay  for  nesting  and  heterogeneity  is  a  runtime 
penalty  ranging  from  1.3  to  1.9  for  complex  objects  (std: :  string  in  our  tests)  and  2.9  to  13  for  built  in  types 
(int).  _ 

Furthermore,  we  want  to  note  that  due  to  the  extensive  use  of  the  new  operator  in  our  element  classes,  the 
tests  depend  heavily  on  the  applied  memory  allocation  scheme.  Therefore  our  source  code  includes  the  smart 
memory  allocator  presented  in  [5],  which  speeds  up  the  tests  significantly  compared  to  the  default  new  operator. 

Our  classes  make  heavy  use  of  new  0'''+  language  features  like  RTTI  and  templates.  We  were  able  to  compile 
our  code  at  the  time  of  this  writing  with  egcs  1.1  [3],  the  EDG  front-eiid  [4]  and  IBM  VisualAge  C++  4.0  [6], 

4  Results 

We  presented  two  distinct  approaches  to  the  problem  of  implementing  a  nested,  heterogeneous  container  in  C++. 
The  classical  one  shows  better  runtime  performance.  Its  overhead,  compared  to  a  standard  STL  container,  arises 
from  the  pointer  indirection,  which  is  necessary  for  the  polymorphic  approach,  and  the  virtual  table  pointer  in 
the  Elemo  class  (see  Figurel).  This  generic  wrapper  frees  the  user  of  boring  work.  One  drawback  is  the  pointer 
semantics,  uncommon  in  the  value  semantics  of  STL  containers.  It  also  forces  the  user  to  handle  most  aspects 
of  memory  management. 

®  Type  identity  is  defined  as  name  identity  here. 
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Figure2.  All  tests  ran  on  a  Pentium  II,  333  MHz,  128MB  machine  under  Windows  NT  4  and  were  compiled  with  egcs 
1.1.1.  The  container  size  is  400000  elements.  ■  ' 

The  container  based  on  chameleon  objects  offers  syntactic  elegance  that  equals  untyped  data  structures, 
like  those  present  in  Scheme.  Operations  on  elements  are  inherently  type-safe,  type  violations  are  signalled  by 
exceptions.  All  this  is  made  possible  by  the  seamless  integration  of  STL  containers  with  the  Value  class.  It  hides 
much  of  the  details  of  casting  and  type  checking  from  the  user,  which  is  still  visible  in  our  classical  approach. 
No  efforts  must  be  taken  by  the  user  to  adapt  objects  for  storage  in  the  nested  container.  The  beauty  of  this 
approach  is  bought  at  the  cost  of  increased  runtime. 

Our  classes  leave  it  up  to  the  programmer  to  choose  either  faster  executing  code  or  more  elegant  source 
code. 


5  Future  Work 

We  currently  focus  on  implementing  a  flat_iterator,  which  behaves  like  a  simple  sequence  iterator  and 
traverses  all  elements  in  a  nested  sequence  in  depth  first  order.  This  iterator  enables  us  to  use  STL  algorithms 
on  our  nested  sequences. 

Another  interesting  question  will  be  the  use  of  different  memory  allocators  and  the  implementation  of  garbage 
collection  ([10])  for  the  objects  stored  in  the  containers.  W'e  believe  this  task  can  be  addressed  efficiently  and 
transparently  for  the  user  through  the  introduced  element  classes  Elemo  and  Value,  respectively. 

Finally,  one  can  think  of  a  reference  counting  mechanism,  implemented  also  through  the  mentioned  element 
classes,  which  can  lead  to  a  dramatical  performance  increase,  especially  in  situations  where  deeply  nested 
containers  are  heavily  copied  for  read  only  purposes. 
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Introduction 

/ 

Java  [7]  is  a  new  programming  language  that  integrates  many  useful  features  of  modern  languages  such  as  C++ 
and  Oberon-2.  Exceptions  are  elaborated  as  a  quite  natural  mechanism  highly  integrated  with  other  parts  of 
the  Java  language.  Exceptions  may  be  thrown  by  the  methods  of  the  standard  Java  classes,  and  a  user  program 
may  catch  and  handle  them.  It  is  clear  that  exceptions  will  be  widely  used  in  Java  programs. 

Exceptions  pose  new  challenge  to  developers  of  data  flow  analyses.  An  exception,  raised  in  a  method  body, 
induces  a  control  flow  other  than  the  main  control  flow  from  the  method  call.  So,  at  the  end  of  the  method 
body,  a  proper  analysis  must  separate  the  data  flow  calculated  for  the  raised  exception  from  the  main  data  flow. 
Now,  a  typical  data  flow  analyser  either  ignores  exceptions  or,  in  the  best  case,  mixes  data  flow  for  the  raised 
exception  with  the  main  data  flow.  The  only  known  approach  of  truly  analysis  of  programs  with  exceptions  is 
described  in  [1]. 

Data  flow  analysis  implemented  in  the  static  error  checker  OSA  (Oberon-2/Modula-2  Static  Analyser)  [2] 
ignores  exceptions  in  Modula-2  programs.  Of  course,  OSA  analysis  is  not  correct  for  exceptions.  Nevertheless, 
there  was  almost  no  problem  with  it  so  far  because  exceptions  are  rarely  used  in  real  programs.  For  the  OSA 
analysis  of  Java  programs  to  be  true,  a  proper  analysis  of  the  exception  handling  is  needed.  In  Java  programs,  the 
catch  clauses  would  be  rarely  executed  and  therefore  difflcult  for  testing.  So  for  non-trivial  exception  handling, 
it  is  highly  probable  for  the  static  analyser  to  find  errors  induced  by  exception  handling. 

In  our  data  flow  analysis,  the  implicit  control  flow  for  the  raised  exceptions  is  represented  explicitly.  The 
hypergraph  representation,  previously  applied  for  the  statements  of  Oberon-2/Modula-2  programs,  is  used  for 
the  new  control  flow  structures  of  analysed  Java  programs. 

1  Data  Flow  Analysis  Overview 

The  static  error  checker  OSA  (http://www.xds.ru/osa/)  checks  programs  for  run-time  errors  by  analysing 
the  source  code.  The  powerful  data  flow  analysis  used  in  OSA  is  able  to  detect  various  kinds  of  Modula-2  and 
Oberon-2  dynamic  semantics  violations,  which  are  usually  found  during  debugging  and  testing  stages  of  program 
development. 

All  known  to  us  source  code  checkers  (e.g.  for  the  C/C-l — b  languages)  that  detect  run-time  errors  may 
produce  only  long  lists  of  warnings  due  to  weakness  of  analysis  they  perform.  In  order  for  a  source  code  checker 
to  be  useful  in  practice,  it  must  be  able  to  recognize  definite  errors  for  really  complicated  erroneous  situations.  It 
is  shown  [2]  that  at  least  the  context-sensitive  data  flow  analysis  with  approximation  of  definite  def-use  relations 
must  be  done  in  such  a  static  error  checker. 

OSA  includes  the  following  analyses: 

-  context-sensitive  and  context-insensitive  data  flow  analyses; 

—  approximation  of  the  definite  def-use  relations  along  with  the  possible  ones; 

-  calculation  of  variable  values:  points- to  must-  and  may-aliasing  analyses  for  reference  variables  and  propaga- 
.  tion  of  value  ranges  for  variables  of  scalar  types; 

—  calculation  of  branch  reachability  for  conditional  statements; 

-  refinement  of  variable  definitions  through  conditions  for  the  branches  of  conditional  statements; 

—  approximation  of  previous  instances  of  heap  variables  and  local  variables  of  recursive  procedures. 

OSA  analysis  is  structured  as  a  sequence  of  the  following  analysis  phases: 
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—  context-insensitive  analysis  phase; 

—  context-sensitive  analysis  phase; 

—  variable  value  calculation  phase; 

—  backward  analysis  of  unused  values  of  variables; 

—  error  analysis  phase. 

Except  the  fourth  phase,  all  analyses  are  forward.  Data  flow  analysis  is  implemented  as  abstract  interpretation 
of  a  program  [5].  Data  flow  representation  is  based  on  the  SSA  form  [3].  At  every  program  point,  a  Def  context 
is  calculated  as  a  result  of  the  interpretation.  A  Def  context  is  the  set  of  variable  definitions  that  are  valid  at 
the  program  point.  The  Def  context  produced  by  the  first  phase  for  the  entry  of  each  method  is  used  as  upper 
approximation  in  the  second  analysis  phase. 

In  data  flow  analysis,  the  control  flow  is  represented  by  a  structure  different  from  the  traditional  control 
flow  graph.  A  program  statement  is  a  hyperleg  that  is  a  construct  with  one  entry  and  possibly  more  than  one 
exit.  For  example,  a  loop  body  with  the  break  and  return  statements  is  represented  as  a  hyperleg  with  at  least 
the  following  three  exits: 

—  for  normal  loop  body  end;  , 

—  via  break  statement; 

—  via  return  statement. 

The  whole  program  is  represented  as  a  hierarchical  hypergraph  [4].  The  control  structures  of  statements  of 
the  program  source  code  are  preserved  in  the  hypergraph  representation. 

'2  Java  Subset  Implemented 


There  are  Java  language  features  which  implementation  in  data  flow  analysis  is  impossible  or  highly  ineffective. 
The  finalize  methods  are  ignored.  The  order  of  the  static  initializations  of  classes  in  the  OSA  analysis  may 
be  other  than  declared  by  the  Java  semantics.  OSA  cannot  analyse  programs  with  classes  that  are  defined 
dynamically  in  the  process  of  execution  of  a  Java  program.  The  Java  subset  implemented  excludes  threads; 
their  implementation  is  now  in  the  development  stage.  Runtime  exceptions  (null  dereference,  division  by  zero, 
etc.)  are  handled  by  the  OSA  analysis  only  if  they  were  recognized  as  definite;  possible  exceptions  are  ignored 
because  their  implementation  would  be  ineffective  and  as  a  rule  useless.  Of  course,  OSA  analysis  would  be  not 
correct  if  an  algorithm  specially  exploits  runtime  exceptions.  So  full  processing  of  runtime  exception  may  be 
turned  on  by  an  OSA  user.  The  Java  subset  implemented  currently  in  OSA  is  almost  the  same  as  in  [1]. 


3  Structures  for  Exception  Handling  Analysis 

Unlike  the  approach  [1],  the  implicit  control  flow  for  the  raised  exceptions  is  represented  explicitly  in  our  data 
flow  analysis.  The  difficulty  is  that  the  additional  coptrol  flow  structures  must  be  constructed  dynamically  in 
the  process  of  data  flow  analysis. 

For  each  throw  statement,  an  exception  branch  is  introduced.  An  exception  branch  has  a  label  and  a  Def 
context  in  the  point  of  the  throw  statement.  A  label  is  the  set  of  types  of  exceptions  that  raised  by  this  exception 
branch.  When  a  throw  statement  is  interpreted  in  data  flow  analysis,  the  exception  branch  associated  with  this 
throw  statement  is  attached  to  the  current  exception  plateau.  A  plateau  is  the  place  where  exception  branches 
are  collected  for  their  further  processing.  There  are  three  kinds  of  exception  plateaus: 

-  catch  plateau  inserted  after  the  try  block  and  before  the  first  catch  clause; 

-  finally  plateau  inserted  before  the  finally  block; 

-  end  method  plateau  placed  in  the  end  of  method  body. 

Each  exception  branch  reached  the  end  method  body  is  placed  into  the  end  method  plateau.  When  the 
interpretation  of  the  method  body  has  completed,  this  exception  branch  is  connected  with  some  additional 
exception  exit  of  the  method.  So  a  method  body  is  represented  in  data  flow  analysis  by  the  following  hvperleg; 
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where  exiti,...,exitfc  are  exception  exits.  An  exception  exit  has  a  label  (the  same  as  for  exception  branch)  and 
a  Def  context. 

A  method  call  is  represented  by  the  hyperleg  of  the  same  structure  as  for  method  body.  Each  call  exit  begins 
some  branch  of  a  program.  An  exception  exit  of  a  method  call  begins  some  exception  branch  which  label  is  the 
same  as  for  the  exit.  In  the  end  of  the  interpretaion  of  a  method  call,  the  exception  branch  associated  with  an 
exception  exit  of  the  call  is  attached  to  the  current  exception  plateau. 

4  Implementation  of  Exception  Handling  , ' 

After  the  interpretation  of  a  try  block  has  completed,  the  catch  plateau  of  the  try  statement  is  interpreted. 
For  each  exception  branch  included  to  the  plateau,  the  branch  label  is  matched  to  parameters  of  catch  clauses, 
according  to  the  Java  language  semantics.  As  a  result,  the  exception  branch  is  attached  either  to  some  catch 
clause  or  to  the  plateau  of  the  innermost  enclosing  construct.  If  more  than  one  exception  branch  is  attached  to 
some  catch  clause,  the  merge  statement  for  the  entering  Def  contexts  would  be  inserted  before  the  catch  clause. 
If  the  branch  label  is  partially  matched  to  the  parameter  of  any  catch  clause,  the  branch  label  is  splitted,  and 
the  new  exception  branch  is  created  with  the  part  of  the  label  that  not  matched  to  the  catch  clause  parameter. 
This  exception  branch  would  be  matched  to  the  rest  of  catch  clauses. 

In  the  inner  program  representation,  a  finally  block  is  represented  as  an  independent  procedure  whose  calls 
are  inserted  into  all  appropriate  places  of  the  try  statement.  Such  decision  guarantees  that  different  data  flows 
in  the  try  statement  would  be  never  mixed.  For  each  exception  branch  of  the  finally  plateau,  the  call  of  the 
finally  block  is  dynamically  inserted;  in  accordance  with  the  Java  language  semantics,  the  main  exit  of  this  call 
is  labeled  with  the  exception  branch  label. 

After  interpretation  of  a  method  body  has  completed,  the  end  method  plateau  is  interpreted.  For  all 
exception  branches  of  the  end  method  plateau,  the  method  exits  are  dynamically  constructed  so  that  the 
following  conditions  true:  . 

-  the  label  of  each  exception  branch  is  a  subset  of  the  union  of  labels  of  method  exits; 

-  for  each  exception  branch  and  for  each  method  exit,  the  exit  label  either  a  subset  of  the  branch  label,  or 

branch  and  exit  labels  do  not  intersect. 

These  conditions  guarantee  that  data  flows  of  two  exception  branches  with  different  labels  would  be  never 
mixed.  If  several  exception  branches  are  connected  with  on6  method  exit,  a  merge  statement  for  the  entering 
Def  contexts  would  be  inserted  to  produce  the  target  Def  context  for  the  exit. 

For  a  method  call,  data  flow  analysis  calculates  all  methods  that  may  be  invoked  by  this  call.  For  each 
invoked  method  and  for  each  exception  exit  in  this  method,  the  call  must  include  exit  with  the  same  label  as 
for  the  method  exit.  If  this  is  not  true,  the  new  exit  with  the  needed  label  is  created  for  the  call. 

5  Related  Work 

The  only  known  data  flow  analysis  approach  that  properly  handles  exceptions  is  described  in  [1],  In  that  article, 
data  flow  information  (the  conditional  points-tos)  may  be  additionally  labeled  with  exceptions.  This  is  a  natural 
but  not  trivial  extension  of  the  context-sensitive  Landi-Ryder  pointer  aliasing  algorithm  [6]. 

The  problem  of  fast  static  calculation  of  possible  uncaught  exceptions  in  SML  programs  was  solved  [8].  A 
program  call  graph  and  exception  flows  are  estimated  from  sets  of  equations  and  constraints.  According  to 
the  Java  language,  this  problem  is  actual  only  for  runtime  exceptions  that  are  unchecked.  The  analyser  OSA 
produces  messages  for  uncaught  runtime  exceptions  only  if  they  were  recognized  as  definite. 
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6  Conclusion 

Unlike  the  approach  [1],  the  implicit  control  flow  for  the  raised  exceptions  is  represented  explicitly  in  our  data 
flow  analysis.  Actually,  this  is  an  application  of  the  hypergraph  representation  (previously  used  for  statements) 
to  the  method  body  and  method  call  constructs.  So  far  the  control  flow  structures  of  the  analysed  program  are 
constructed  before  data  flow  analysis.  Here  the  new  control  flow  structures  for  exception  flows  are  constructed 
dynamically  under  control  of  data  flow  analysis. 

Our  realization  of  the  exception  handling  by  means  of  the  extension  of  the  control  flow  mechanism  appears 
to  be  considerably  less  complicated  than  in  [1]. 

Authors  are  grateful  to  Dmitry  Leskov  for  many  useful  critical  notes  concerning  this  paper. 
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Abstract.  In  distributed  object  systems,  one  has  the  possibility  to  make  method  invocations  on  objects 
located  on  other  host.  During  such  an  invocation,  data  is  sent  to  another  host  and  back.  However,  the 
system  tries  to  hide  this  and  simulate  a  standcard  method  invocation'as  close  as  possible.  Some  systems 
[Voyager]  try  to  offer  other  invocation  semantics,  e.g.  asynchronous  method  invocation.  We  try  to  go  a 
step  further  and  offer  the  actual  invocation  as  first  class  abstractions.  The  programmer  can  build  his  own 
abstractions  by  either  implementing  his  own  or  by  combining  existing  abstractions.  Wi1,h  this  system,  he  can 
build  arbitrary  invocations  semantics,  e.g.  synchronous  method  invocation  with  transactional  semantics, 
which  also  logs  all  method  invocations. 


1  Overview 

Today’s  highly  interconnected  systems  put  more  and  more  emphasis  on  the  exploitation  of  the  advantages 
inherent  to  a  network,  i.e.  increased  fault  tolerance,  better  availability,  and  easier  scalability.  However,  network 
systems  have  their  disadvantages  as  well,  and  it  is  not  easy  to  actually  exploit  their  advantages.  Independent 
failure  modes,  which  have  to  be  handled  when  dealing  with  several  computers,  increase  the  complexity  of  software 
development.  Additionally,  networked  systems  are  often  heterogeneous  and  highly  dynamic.  The  configuration 
of  available  computation  resources  may  change  on  a  moments  notice.  To  cope  with  these  problems  different 
approaches  have  been  proposed.  A  common  approach  is  to  put  part  of  the  additional  complexity  into  the  object 
system,  i.e.,  to  hide  it  from  the  developer,  by  extending  the  notion  of  objects  and  classes. 

However,  distributed  object  systems,  e.g.  Object  Management  Group’s  OMG  [OMG],  Microsoft’s  DCOM 
[Micro],  or  JavaSoft’s  Remote  Method  Invocation  [RMI98]  use  a  fix  scheme  of  a  point-to-point  request /response 
communication  model.  While  appropriate  for  a  subset  of  applications  using  distributed  objects,  this  model 
inhibits  exploiting  the  advantages  of  distributed  objects  for  other  domains.  Other  work  has  been  done  to  widen 
the  application  domain  for  distributed  objects  by  introducing  new  kinds  of  method  invocation  semantics,  e.g. 
Voyager  [Voyager]  which  introduces  asynchronous  method  invocation.  This  paper  describes  a  novel  approach 
to  widen  the  application  domain  for  distributed  objects  even  further.  We  claim  that  introducing  new  special 
cases  as  done  e.g.  in  Voyager  is  not  sufficient.  There  are  an  infinite  number  of  possible  desirable  kinds  of  method 
invocation,  e.g.  asynchronous  vs.  synchronous,  unicast  vs.  multicast,  replicated,  transactional,  logged,  or  atomic. 
We  claim  that  just  as  any  other  aspect  of  a  distributed  system,  the  "invocation  style”  should  be  a  first  class 
abstraction.  One  should  be  able  to  compose  abstractions  pd  use  the  most  adequate  ones  according  to  the 
application  needs. 


1.1  Distributed  Object  Methology 

A  client  sees  an  object  as  a  reference  into  memory,  some  data  fields,  and  a  set  of  type  bound  procedures 
(methods).  An  application  does  not  have  to  distinguish  between  local  and  remote  objects. 

The  application  has  transparent  access  to  all  objects  regardless  of  their  actual  location.  For  every  accessed 
remote  object,  the  system  automatically  generates  a  so-called  istub  object.  A  stub  object  is  the  local  represen¬ 
tative  (placeholder)  of  an  object  located  on  another  site.  It  offers  exactly  the  same  interface  as  its  associated 
actual  object,  but  redirects  incoming  requests  to  the  actual  object.  The  request  (object  ID,  invoked  method,  and 
actual  parameters)  is  transformed  (marshalled)  to  a  byte  stream,  which  is  sent  from  the  stub  to  the  skeleton. 
This  stream  includes  all  information  needed  to  reconstruct  the  receiver  object,  the  called  method,  and  the  actual 
parameters.  This  mechanism  is  similar  to  the  RPC  mechanism  [BiNeS4,Tan95],  except  that  a  receiver  object  is 
passed  along  with  each  new  invocation. 
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1.2  Code  Generation  for  Stub  and  Skeleton 

Stub  and  skeleton  code  is  generated  automatically  from  the  interface  definition  of  the  given  class.  Typical  stub 
and  skeleton  code  consists  of  three  parts: 

1.  Marshalling  of  all  input  parameters 

2.  Activation  of  the  transport  mechanism  in  order  to  signal  the  actual  object  the  intercepted  method  invocation. 

3.  Unmarshalling  of  output  parameters  and  the  return  value 

Logically  seen  we  introduce  one  new  additional  layer  (see  Fig.  1).  A  method  invocation,  which  is  not  handled 
locally,  is  intercepted  by  its  corresponding  stub  method.  Each  stub  method  is  tailored  to  its  method  and  is  mainly 
concerned  with  marshalling.  After  the  marshalling  is  done,  the  stub  code  calls,  regardless  of  the  invocation  mode, 
the  global  invocation  handler.  This  handler  chooses  and  activates  the  previously  assigned  invocation  mode.  The 
structure  of  the  invocation  modes  is  explained  in  the  next  section. 


client: 


obj.MlstubO: 

/  marshall  paramete: 
obj.MlO  HandleInvokeO 

unmarshall  par^eters 


HandleInvokeO: 

Invoke  remote  method  with 
appropriate  invocation  mode 


Fig.  1.  Control  flow  on  method  invocation 


In  our  current  prototype  implementation,  we  achieve  this  behaviour  without  introducing  a  new  layer  by 
using  an  array  of  invocation  abstractions.  Each  stub  knows  the  method  to  be  used  and  chooses  the  correct 
one  through  an  index  into  an  invocation  array.  With  help  of  this  mechanism  we  avoid  the  additional  layer  and 
achieve  a  faster  dispatch. 

2  Generating  Invocation  Modes 

We  oflFer  the  programmer  a  class  hierarchy  of  invocation  abstractions,  ilnvocation  is  the  abstract  base  class. 
Whenever  an  object  is  to  be  exported  (made  public  to  other  hosts),  the  programmer  must  specify  the  desired 
invocation  modes  for  every  method  of  the  object  he  exports.  One  can  have  an  individual  invocation  configuration 
for  each  object  of  a  class  or  reuse  a  configuration  for  all  objects  of  the  same  class. 

To  export  an  object  one  has  to  call  the  procedure  Export  that  is  part  of  a  library.  One  has  to  specify  the 
host  on  which  the  given  object  is  exported,  the  name  of  the  object  and  the  desired  invocation  abstractions.  As 
a  result  of  this  operation,  the  system  generates  ’oii-the-fly’  the  necessary  skeleton  code  to  access  this  object  (see 
example  below). 

invoke  :=  lnvocations.GetClasslnfo("className’'); 

//...  modify  abstractions  to  current  needs  < 

Export(obJectl,  host,  namel,  invoke); 

//  ...  modify  abstractions  if  necessary 
Export(object2,  host,  name2,  invoke); 

When  a  client  imports  an  object,  it  calls  the  procedure  ilmport.  One  has  to  specify  the  name  the  object 
and  the  host  where  it  resides.  An  appropriate  request  is  sent  to  the  server  host.  The  server  host  sends  back  two 
kinds  of  information.  First,  the  invocation  abstractions  of  the  exported  object  and  second,  the  actual  object 
data.  With  help  of  the  received  invocation  abstractions  the  necessary  stub  code  is  generated  and  the  actual 
object  is  generated. 

lmport(obj,  host,  name); 

The  necessary  invocation  information  is  generated  with  a  call  to  iGetClassInfo,  which  uses  meta-programming 
facilities  to  collect  it.  It  returns  the  default  invocation  information  for  a  class.  If  an  object  is  exported  with  this 
information,  one  gets  the  following  default  behaviour: 
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1.  Methods  are  called  synchronous  with  the  standard  semantics  of  method  calls. 

2.  Parameters  of  a  pointer  type  are  copied  using  deep-copy  semantics. 

3.  If  a  method  returns  a  pointer  value,  the  referenced  object  is  copied  to  the  caller. 

These  three  standard  behaviours  can  be  changed  as  described  in  the  following  three  sections. 


2.1  Changing  the  Invocation  Mode 

By  default,  all  method  invocations  are  handled  as  standard  method  invocations,  i.e.  synchronous.  However,  one 
can  change  the  behaviour  as  needed  by  composing  your  own  invocation  abstractions.  Either  one  can  create  a 
new  abstraction  that  suits  the  current  necessities,  or  one  can  compose  one  with  help  of  existing  abstractions 
using  the  decorator  pattern  [Gam95].  Let-fs  look  at  some  examples: 

1.  A  asynchronous  invocation  abstraction,  which  uses  replication  and  logs  the  invocations: 

VAR 

myinvoke;  Invocation; 

myinvoke  :=  LogMode(ReplicationMode(ASynclnvocation())); 

2.  A  synchronous  invocation  with  transaction  semantics:  ' 

VAR 

myinvoke:  Invocation; 

myinvoke  TransactionMode(Synclnvocation()); 

3.  After  generation  of  the  desired  invocation  abstraction  one  can  assign  it  to  the  desired  method(s)  and  assign 
it  to  an  exported  object: 

invoke. Method(" name  of  method",  myinvoke); 

Export(obj,  host,  name,  invoke): 


If  one  wants  to  implement  an  own  transaction  invocation  one  has  to  create  a  new  subclass  of  the  class 
ilnvocation  and  overwrite  the  method 


PROCEDURE  (i;lnvocation)  lnvoke(obj:PTR;  id:LONGINT:  s;Stream):Stream; 


The  method  will  be  called  whenever  a  method  that  uses  this  invocation  abstraction  is  activated,  lobj  is 
the  invoked  method,  lid  contains  a  unique  number  defining  the  called  method  and  is  contains  the  marshalled 
parameters.  The  method  has  to  return  the  linearized  return  value  and  output  parameters. 

2.2  Changing  the  copy-mode  for  individual  parameters 

Method  can  have  pointer  parameters.  This  implies,  if  the  method  is  executed  remotely,  that  the  referenced 
objects  have  to  be  transferred  from  the  client  to  the  server  and  back.  Either  one  can  make  a  deep  copy,  actually 
generating  a  copy  of  the  referenced  object  on  the  other  host,  or  one  can  make  a  shallow  copy.  A  pointer  parameter 
copied  in  shallow  copy  mode  is  not  transferred  to  the  server.  Instead,  the  object  is  automatically  exported  with 
an  anonymous  name.  On  the  server  side,  before  the  server  method  is  invoked,  a  corresponding  import  statement 
is  executed  automatically  (see  Fig.  2). 

2.3  Changing  the  copy  mode  of  the  return  value 

Methods  can  return  pointer  values.  This  implies,  if  the  method  is  executed  remotely,  that  the  referenced  object 
has  to  be  transferred  from  the  server  to  the  client  host.  As  with  pointer  parameter  (section  2.2)  one  has  the 
possibility  to  make  a  deep  or  a  shallow  copy,  i.e.  the  procedure  returns  either  the  actual  object  (deep  copy)  or 
another  stub  object  (shallow  copy). 
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Fig.  2.  Shallow  copy  of  parameter 

3  Conclusions 

A  method  invocation  that  is  not  handled  locally  is  intercepted  by  its  corresponding  stub  method.  Each  stub 
method  is  tailored  to  its  method.  The  stub  is  concerned  mainly  with  marshalling.  The  actual  invocation  is 
delegated  to  the  procedure  iHandlelnvocation  (see  Fig.  1).  When  called,  iHandlelnvocation  decides  on  the 
actually  used  invocation  mode: 

Handleinvocation  (rec;  PTR;  id:  LOIMGINT;  data:  Stream)  :  Stream; 
info  :=  ...  Invocation  information  for  the  object  rec 
invoke  :=  invoke  mode  for  method  id  in  info 
data  :=  invoke.lnvoke(rec,  id,  data) 

RETURN  data 

An  actual  implementation  of  Invoke  will  do  some  invocation  specific  statements  (open/close  transaction...) 
and  delegate  the  invocation  to  the  decorated  invocation  mode,  e.g.  for  the  invocation  mode  resulting  from  the 
statement 

invoke  :=  LogMode(TransactionMode(Synclnvocation())); 
the  actual  sequence  of  invocation  modes  is  as  shown  in  Fig.  3. 


Fig.  3.  Example  abstraction  sequence 

The  invocation  mode  is  defined  only  at  runtime  when  an  object  is  exported.  Each  time  one  exports  an  object, 
one  can  choose  other  invocation  abstractions. 
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The  development  of  a  new  object-oriented  language  named  Java  and  its  successful  application  in  the  Internet 
technologies  stimulates  interest  to  use  it  as  a  tool  for  creating  parallel  and  distributed  programs  [1],  [2],  [3]. 
The  main  advantages  of  the  Java  language  are  platform  independent  code  that  allows  to  run  programs  on  any 
hardware  without  recompilation  and  perfect  realization  of  object-oriented  paradigm  that  allows  to  design  the 
architecture  of  complex  program  systems  very  closely  to  the  language  of  realization.  The  standard  Java  library 
includes  low-level  tools  for  creating  multi-threaded  processes  and  calling  methods  of  remote  objects.  Those  tools 
may  serve  as  a  base  of  a  class  library  for  developing  distributed  programs. 

In  this  work  we  offer  a  high-level  development  framework  for  creating  distributed  programs.  Suggested 
approach  is  based  on  the  recursive-parallel  methodology  [6].  Distribution  models  are  represented  in  the  form 
of  Java  classes  which  are  called  distribution  stencils.  Each  class  has  a  definite  meaning  and  a  set  of  abstract 
methods.  Each  of  those  methods  must  be  redefined  by  the  developer  to  suitable  one  for  his  task.  The  distribution 
itself  is  performed  by  final  methods  of  stencils,  thus  hiding  parallelization  details  from  an  application  developer. 

The  development  framework  is  based  on  two  main  hierarchies.  A  class  hierarchy  of  the  distribution  stencils 
representing  models  of  parallel  execution,  and  an  interface  hierarchy  of  parameter  blocks.  Implementation  of 
some  interface  from  parameter  block  hierarchy  is  responcible  for  dividing  task  into  subtasks.  The  base  of  all 
distribution  stencils  is  an  Activation  class. 

abstract  public  class  Activation  implements  Runnable  { 
public  Activation(ParamBlock  pb)  ■{ 
param  =  pb; 

//  ... 

> 

abstract  public  void  run() ; 

public  void  joinO  throws  InterruptedException  { 

n  ... 

} 

protected  ParamBlock  param; 

} 

The  activation  and  all  its  subclasses  receive  task  data  as  a  reference  to  the  interface  ParamBlock  or  some 
subinterface.  A  concrete  subclass  of  activation  must  know  how  to  interact  with  this  interface  to  divide  the  task 
into  subtasks  and  retreive  data  objects  for  calculations.  The  abstract  method  run  is  the  main  method  where  the 
calculation  on  a  current  subtask  is  performed.  It  was  usually  overridden  by  subclasses  to  implement  a  certain 
distribution  model.  The  method  join  of  the  Activation  class  performs  synchronization  of  the  executed  activation 
and  the  current  thread. 

The  classes  RPDihotomy  and  RemoteLoad  extend  the  class  Activation  for  realization  the  recurcive-parallel 
paradigm.  The  method  run  of  the  class  RPDihotomy  performs  recursive-parallel  dividing  of  the  task  using  the 
binary  tree  scheme.  A  subtask  is  divided  from  the  root  to  the  leafs  of  the  tree  and  then  the  results  are  collected 
from  the  leafs  to  the  root.  If  the  current  subtask  is  small  enough,  the  run  method  calls  the  abstract  method  Leaf 
which  performs  sequential  calculations.  Otherwise  it  retrieves  left  and  right  subtasks  using  methods  of  interface 
RPDivider  realized  by  the  current  parameter  block.  When  the  abstract  method  Init  performed  the  preparation 
of  two  subtasks  two  new  activations  of  the  same  class  as  the  original  one  are  created  and  started  in  parallel  with 
the  appropriate  subtask  as  a  parameter  block.  When  two  activations  are  finished  the  abstract  method  Merger 
is  called  for  uniting  the  results  of  two  subtasks. 
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public  abstract  class  RPDihotomy  extends  Activation 

{ 

public  RPDihotomy (RPDivider  pb)  { 
super  (pb)  .; 

> 

abstract  protected  void  Init (RPDivider  pbl,  RPDivider  pb2) ; 
abstract  protected  void  Leaf(); 

abstract  protected  void  Merger (RPDivider  pbl,  RPDivider  pb2) ; 
public  void  run()  { 

RPDivider  param  =  (RPDivider)this,paxEim; 
if(  param.getSizeO  >  param. getThresholdC)  )  { 

RPDivider  pi  =  param.f irstHalf () ; 

RPDivider  p2  =  param. lastHalf () ; 

Init (pi, p2) ; 
try  { 

RPDihotomy  al  = 

(RPDihotomy)Cluster.newActivation(getClass()  ,pl) ; 

RPDihotomy  a2  = 

(RPDihotomy)Cluster.newActivation(getClass()  ,p2) ; 

al.joinO; 

a?.join(); 

Merger (p 1, p2) ; 

> 

catch(  InterruptedException  e)  { 

} 

catch(  Throwable  e)  -[ 

n  ... 

> 

Jelse 

LeafO; 

} 

} 

The  class  RemoteLoad  is  used  to  effectively  organize  sequential  calculations.  Its  method  run  performs  a 
subtask  in  one  iteration  of  a  sequential  cycle  while  data  objects  for  next  iteration  are  downloaded  on  the 
background. 

public  abstract  class  RemoteLoad  extends  Activation  ■{ 

public  RemoteLoad (RemoteRef  pb)  { 
super (pb) ; 

> 

abstract  void  InitO; 
abstract  void  Body(Object  data); 

public  void  run()  { 

RemoteRef  param  =  (RemoteRef )this .param; 

Object  curdata  =  nextdata  = 

Cluster . loadObj ect (param . getDat aRef 0 )  ; 

Cluster. waitData( ) ; 

InitO; 

for(int  i=l;  Kpb.getSize;  i++)  { 
nextdata  =  Cluster  .loadObj ect  (param.  getDataRefO) ; 

Body (curdata) ; 

Cluster. waitDataO ; 
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curdata  =  nextdata; 

}  ,  ,  ...  ■  '  .  . 

> 

} 

Architecture  of  parallel  environment  is  represented  by  abstraction  of  computing  network  resource  called  cluster 
(Fig.l).  Each  station  in  the  network  can  access  the  cluster  using  his  sequrity  rights  and  distribute  its  task  among 
the  Java-VMs  contained  in  the  cluster.  Cluster  is  a  full  graph  which  vertices  are  Java-VMs  executed  on  stations 
in  the  network  and  ribs  are  communications  between  VMs.  Vertices  and  ribs  have  weights.  Weight  of  a  rib 
indicates  abstract  connectivity  characteristic  and  weight  of  a  vertice  indicates  characteristic  of  VM’s  loading. 
If  there  is  no  communication  between  two  VMs  we  assume  the  maximum  possible  weight  to  the  rib  connecting 
them. 


Fig.  1.  The  structure  of  distributed  Java  virtual  machiue 


Each  activation  executed  on  a  particular  Java-VM  has  access  to  an  instance  of  the  Cluster  class.  This 
instance  is  the  only  way  for  the  activation  to  communicate  with  the  parallel  environment.  So  internal  details  of 
distributing  is  encapsulated  in  the  abstraction  of  cluster.  Cluster  manages  a  list  of  currently  available  Java-VMs, 
proceeds  communication  errors  and  returns  application  errors  to  the  user  console.  Activation  that  has  failed  to 
start  on  one  Java-VM  may  be  redirected  to  another  one  or  executed  on  the  local  host  in  time-sharing  mode 
without  any  effect  to  application  program.  Activation  can  call  newActivation  method  of  the  Cluster  instance 
and  this  instance  will  call  remotely  (using  Java  RMI  [4])  a  method  of  an  instance  of  ActivationServer  on  a 
chosen  remote  host.  ActivationServer  is  executed  on  each  VM  in  the  cluster  and  responcible  for  creating  and 
starting  activations  and  returning  results  to  calling  VM.  Distribution  of  program  classes  code  is  performed  by 
RMIClassLoader  from  RMI  library,  creation  of  class  ihstance  is  performed  using  Java  core  reflection  mechanism 
[5]. 
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Abstract.  We  propose  here  a  simple  framework  for  constraint  programming  in  which  the  programming 
process  consists  of  a  few  easily  identified  components.  This  provides  a  basis  for  a  component-based  frame¬ 
work  for  constraint  programming. 


1  Introduction 

1.1  Motivation 

Constraint  programming  is  an  alternative  approach  to  programming  in  which  the  programming  process  is  limited 
to  a  generation  of  requirements  (constraints)  and  a  solution  of  these  requirements  by  means  of  general  or  domain 
specific  methods. 

The  ongoing  research  in  the  area  of  constraint  programming  led  to  an  identification  of  various  techniques 
and  methods  that  by  now  are  pretty  well  understood  (see,  e.g.,  Tsang  (1993)).  However,  the  expositions  of  these 
techniques  are  usually  long  and  detailed.  This  conceals  the  fact  that  constraint  programming  can  be  explained 
in  simple  terms,  on  less  than  ten  pages.  To  substantiate  this  claim  we  present  here  constraint  programming 
in  a  tutorial-like  fashion  by  emphasizing  the  fact  that  its  main  ingredients  can  be  explained  within  a  simple 
framework. 

The  main  idea  behind  component-based  approach  to  programming  is  that  the  programming  process  is  limited 
to  a  configuration  of  existing,  previously  developed  components.  This  view  of  programming  obviously  facilitates 
program  development,  modification  and  verification. 

We  argue  here  that  the  techniques  used  in  constraint  programming  could  be  put  together  to  create  a 
component-based  framework  for  this  form  of  programming.  In  such  a  framework  the  constraint  programming 
process  could  be  limited  to  an  appropriate  configuration  of  existing  components  and  to  a  specification  of  some 
simple  atomic  actions. 


1.2  Preliminaries 

Let  us  begin  by  introducing  the  relevant  concepts. 

Consider  a  finite  sequence  of  variables  X  :=  xi,..  .,Xn  where  n  >  0,  with  respective  domains  T>  Di,. . 
associated  with  them.  So  each  variable  Xi  ranges  over  the  domain  D^.  By  a  constraint  C  on  X  we  mean  a  subset 
of  £>1  X  ...  X  Dn-  If  C  equals  Di  x  . . .  x  then  we  say  that  C  is  solved. 

By  a  constraint  satisfaction  problem,  CSP  in  short,  we  mean  a  finite  sequence  of  variables  X  :=  xi, . .  .,Xn 
with  respective  domains  V  :=  Di, . .  .,Dn,  together  with  a  finite  set  C  of  constraints,  each  on  a  subsequence  of 
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X.  We  write  such  a  CSP  as  {C  ;  V£),  where  VS  :=  X]_  E  Di,..  .,Xn  e  Dn  and  call  each  construct  of  the  form 
X  e  D  a  domain  expression.  To  simplify  the  notation  we  omit  the  “{  }”  brackets  when  presenting  specific  sets 
of  constraints  C. 

Consider  now  a  CSP  (C  ;  VS)  with  T>£  Xi  E  Di,...,Xn  E  Dn-  We  say  that  an  n-tuple  (di, . .  .,dn)  E 
Di  X  . . .  X  Dn  is  a  solution  to  {C  ;  D£)  if  for  every  constraint  C  eC  on  the  variables  Xi^,.. Xi^  we  have 

(djj )  •  •  -5 di^')  E  C. 

If  a  CSP  has  a  solution,  we  say  that  it  is  consistent  and  otherwise  we  say  that  it  is  inconsistent.  For  further 
discussion  it  is  useful  to  introduce  the  following  simple  notion.  Take  a  sequence  of  variables  X  xi,...,Xn 
with  the  corresponding  sequence  of  domains  D  :=  and  consider  an  element  d  :=  (di,...,d„)  of 

DiX  ...X  Dn  and  a  subsequence  Y  :=Xi^^.. Xii  of  X.  Then  we  denote  the  sequence  {di^ , . . djj  by  d[Y]  and 
call  it  the  projection  of  d  on  T. 

So,  given  a  CSP  V  a  tuple  of  values  from  the  corresponding  domains  is  a  solution  to  V  if  for  every  constraint 
C  of  V  the  projection  of  this  tuple  on  the  sequence  of  the  variables  of  C  satisfies  C. 

Consider  now  two  CSP’s  Vi  and  V2  with  the  same  sequence  of  variables.  We  say  that  Vi  and  V2  are  equivalent 
if  they  have  the  same  set  of  solutions.  This  definition  is  rather  limited  as  it  cdnnot  be  used  to  compare  CSP’s 
with  different  sequences  of  variables.  Such  situations  often  arise,  for  example  when  new  variables  are  introduced 
or  some  variables  are  eliminated. 

To  this  end  we  extend  the  above  definition  of  equivalence  as  follows.  Consider  two  CSP’s  Vi  and  P2  and  a 
sequence  X  of  common  variables.  We  say  that  Vi  and  V2  are  equivalent  w.r.t.  X  if 

—  for  every  solution  d  to  Pi  a  solution  to  V2  exists  that  coincides  with  d  on  the  variables  in  X, 

-  for  every  solution  e  to  P2  a  solution  to  Vi  exists  that  coincides  with  e  on  the  variables  in  X. 

Using  the  earlier  introduced  notion  of  projection,  we  can  define  this  notion  of  equivalence  in  a  more  succinct 
way:  Vi  and  P2  are  equivalent  w.r.t.  X  iff 

{d[X]  I  d  is  a  solution  to  Pi)  =  {d[X]  |  d  is  a  solution  to  P2}. 

Clearly,  two  CSP’s  with  the  same  sequence  of  variables  X  are  equivalent  iff  they  are  equivalent  w.r.t.  X,  so 
the  latter  notion  of  equivalence  is  a  generalization  of  the  former  one.  When  transforming  CSP’s  one  often  tries 
to  maintain  equivalence  w.r.t.  to  the  initial  sequence  of  variables. 

Finally,  given  three  CSP’s  P,Pi  and  P2  with  the  same  sequence  of  variables,  we  say  that  the  union  ofVi 
and  P2  is  equivalent  to  V  if 

-  every  solution  to  P  is  a  solution  to  either  Pi  or  to  P2, 

—  every  solution  to  Pi  or  to  P2  is  a  solution  to  P. 

In  the  presentation  below  we  use,  often  informally,  a  proof  theoretic  framework  of  Apt  (1998)  that  allows 
us  to  write  transformations  of  CSP’s  in  a  succinct  way.  In  this  framework  the  proof  rules  act  on  CSP’s.  Various 
relevant  concepts  such  as:  an  application  of  a  rule  to  a  CSP,  a  CSP  closed  under  a  set  of  rules,  and  derivation 
can  be  made  formal.  In  particular,  the  rules  that  preserve  equivalence  are  called  sound.  All  rules  here  presented 
are  easily  seen  to  be  sound. 


2  A  General  Framework 

We  begin  by  formulating  a  general  framework  for  constraint  programming  that  we  shall  use  to  explain  its  specific 
aspects. 

First,  we  formulate  our  initial  problem  as  a  CSP.  This  in  itself  can  be  a  non-trivial  problem.  In  particular, 
at  this  stage  we  have  to  take  decisions  concerning  the  choice  of  variables,  domains  and  constraints.  This  stage 
of  constraint  programming  is  called  modelling  and  in  contrast  to  programming  in  other  programming  styles  it  is 
more  time  consuming  and  more  involved.  Modelling  is  more  an  art  than  science  and  a  number  of  rules  of  thumb 
and  various  heuristics  are  useful  at  this  stage  — see  for  instance  Section  8.4  “Different  Problem  Modelling”  in 
Marriott  &:  Stuckey  (1998). 

Subsequently,  we  apply  to  the  formulated  CSP  the  following  procedure: 
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Solve: 

done:=false; 

WHILE  NOT  DONE  DO 
Preprocess; 

Constraint  Propagation; 

IF  Happy 
THEN 
done:=true 
ELSE 
Split; 

Proceed  by  Cases 

END 

END 

where  Proceed  by  Cases  leads  to  a  recursive  invocation  of  Solve  for  each  newly  formed  CSP. 

The  Solve  procedure  represents  the  basic  loop  of  constraint  programming.  In  what  follows  we  briefly  explain, 
in  an  informal  way,  the  meaning  of  all  the  subsidiary  procedures  used  in  SOLVE.  As  the  notion  of  constraint 
propagation  is  central  to  constraint  programming  we  defer  the  discussion  of  it  to  the  end  of  the  section.  At  this 
stage  it  suffices  to  know  that  constraint  propagation  transforms  a  given  CSP  into  another  one  that  is  equivalent 
to  it. 


2.1  Preprocess 

The  aim  of  this  procedure  is  to  bring  the  given  CSP  into  a  desired  syntactic  form.  The  resulting  CSP  should 
be  equivalent  to  the  original  one  w.r.t.  to  the  original  set  of  variables. 

Typical  examples  are  the  transformation  of  Boolean  constraints  into  ones  in  disjunctive  normal  form  and 
the  transformations  that  rewrite  constraints  over  reals  so  that  in  each  constraint  each  variable  appears  at  most 
once.  The  latter  is  done  by  introducing  auxiliary  variables,  which  explains  why  we  need  a  more  general  notion 
of  equivalence. 


2.2  Happy 

Informally,  Happy  means  that  the  goal  set  for  the  initial  CSP  has  been  achieved.  What  goal  it  is  depends  of 
course  on  the  applications.  The  following  contingencies  are  most  common: 

-  a  solution  has  been  found, 

-  all  solutions  have  been  found, 

-  a  normal  form”  has  been  reached  from  which  it  is  straightforward  to  generate  all  solutions, 

-  inconsistency  was  detected, 

-  best  solution  w.r.t.  some  quality  measure  was  found,  " ; 

-  all  best  solutions  w.r.t.  some  quality  measure  were  found, 

-  (in  the  case  of  constraints  on  reals)  all  interval  domains  axe  reduced  to  sizes  smaller  than  some  fixed  in 
advance  e. 

In  general.  Happy  can  be  viewed  as  a  test  applied  to  the  current  CSP  in  which  some  additional  parameters 
are  also  taken  into  account. 


2.3  Split 

E  after  termination  of  the  constraint  propagation  the  current  CSP  is  not  in  the  desired  form,  that  is  the  test 
Happy  fails,  this  CSP  is  split  into  two  (or  more)  CSP’s  the  union  of  which  is  equivalent  to  the  current  CSP.  In 
general,  such  a  split  is  obtained  either  by  splitting  a  domain  or  by  splitting  a  constraint. 

In  the  following  tw^o  examples  a  split  of  a  domain  is  represented  by  a  rule  that  transforms  a  domain  expression 
into  two  domain  expressions  separated  by  means  of  the  “j”  symbol. 
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-  Labelling. 

Assume  that  the  domain  D  is  non-empty  and  finite.  The  following  rule  can  then  be  used: 

xeD 

X  6  {a}  \  X  €  D  —  {a} 

where  a  £  D. 

-  Bisection. 

Assume  that  the  domain  is  a  non-empty  interval  of  reals,  written  as  [a. .6],  We  can  then  employ  the  following 
rule:  ' 

X  £  [a..b] 

X  e  [a..^]  j  a:  £  [^..6] 

In  turn,  the  following  two  examples,  also  written  as  rules,  illustrate  a  split  of  a  constraint. 

-  Disjunctive  constraints. 

Suppose  that  the  constraint  is  a  Boolean  disjunction.  The  constituents  of  .this  disjunction  can  be  arbitrary 
constraints.  We  can  then  apply  the  following  rule: 

••Cl  VC's 
'  Ci\C2 

-  Constraints  in  “compound”  form. 

The  idea  is  that  such  constraints  are  split  into  syntactically  simpler  compounds  that  can  be  dealt  with 
directly.  Suppose  for  example  that  we  know  how  to  deal  directly  with  polynomial  equations  on  reals  and 
that  the  constraint  in  question  isp(x)  —  |g|,  where  p(®)  is  a  polynomial  in  the  variables  x  and  a  is  a  constant. 
Then  we  can  use  the  following  rule: 

p(x)  =  |o| 

p(x)  —  a  I  p(x)  —  -a 

Each  split  of  a  domain  or  of  a  constraint  leads  to  a  replacement  of  the  current  CSP  by  two  CSP’s  that 
differ  from  the  current  one  in  that  the  split  domain,  respectively  the  split  constraint,  is  replaced  by  one  of  the 
constituents. 

For  instaiice,  the  above  rule  dealing  with  labelling  leads  to  the  replacement  of  a  CSP 


by  two  CSP’s, 
and 


(C  ;  V£,x£D) 

{C  ;  VS,  X  €  {o}} 

(C  ;  V£,  x  £  D  —  {a}). 


2.4  Proceed  by  Cases 

The  Split  procedure  yields  two  new  CSP’s.  They  are  then  dealt  with  by  means  of  the  Proceed  by  Cases 
procedure. 

The  order  in  which  these  new  CSP’s  are  considered  depends  on  the  adopted  search  technique.  In  general,  due 
to  the  repeated  use  of  the  Split  procedure  a  binary  tree  of  CSP’s  is  generated.  The  purpose  of  the  Proceed 
BY  Cases  procedure  is  to  traverse  this  tree  in  a  specific  order  and,  if  needed,  to  update  the  current  CSP  with 
some  newly  gathered  information  (in  the  case  of  search  for  the  best  solution). 

Two  most  known  of  these  techniques  are  backtracking  and  — when  searching  for  the  best  solution —  branch 
and  bound.  Backtracking  and  branch  and  bound,  when  combined  with  appropriate  instances  of  the  Con¬ 
straint  Propagation  procedure  form  more  complex  forms  of  search  methods  that  are  specific  for  constraint 
programming.  Two  best  known  techniques  are  forward  checking  and  look  ahead. 
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2.5  Constraint  Propagation 

At  this  stage  let  us  return  to  the  Constraint  Propagation  procedure.  In  general,  this  procedure  replaces 
a  given  CSP  by  a  “simpler”  one,  yet  equivalent.  The  idea  is  that  such  a  replacement,  if  efficient,  is  profitable, 
since  the  subsequent  search  resulting  from  the  repeated  calls  of  the  Splh'  and  Proceed  by  Cases  procedures 
is  then  performed  on  a  smaller  search  space. 

What  “simpler”  denotes  depends  on  the  applications.  Typically,  it  means  that  the  domains  and/or  constraints 
become  smaller.  The  constraint  propagation  is  performed  by  repeatedly  reducing  domains  and/or  reducing  con¬ 
straints  while  maintaining  equivalence.  The  stopping  criterion  is  a  local  consistency  notion,  that  is,  a  constraint 
propagation  algorithm  terminates  once  the  final  CSP  satisfies  a  specific  local  consistency  notion. 

Let  us  consider  some  examples.  The  first  two  deal  with  reducing  domains  and  the  other  two  with  reducing 
constraints.  ° 


Hyper-arc  Consistency  This  notion  of  local  consistency  was  introduced  in  Mohr  k  Masini  (1988).  The  name  is 
taken  from  Marriott  k  Stuckey  (1998). 

Definition  1. 

Consider  a  constraint  C  on  the  variables  Xi,. .  .,a;„  with  the  respective  domains  Dy, . .  .,D„,  that  is  C  CDyX 

■■■xDn.  We  call  C  hyper-arc  consistent  if  for  every  i  e  [l..n]  and  a  e  Di  there  exists  d£C  such  that 
a  -  d[xi]. 

—  We  call  a  CSP  hyper-arc  consistent  if  all  its  constraints  are  hyper-arc  consistent.  □ 

Intuitively,  a  constraint  C  is  hyper-arc  consistent  if  for  eyery  involved  domain  each  element  of  it  participates 
in  a  solution  to  C.  In  case  all  constraints  are  binary,  hyper-arc  consistency  reduces  to  the  more  known  notion 
of  arc  consistency  introduced  earlier  in  Mackworth  (1977). 

Consider  now  a  constraint  C  on  the  variables  xy,..  .,Xn  with  the  respective  domains  Dy,. . ., Choose  a 
variable  Xi  and  perform  the  following  operation  on  its  domain  Df. 

remove  from  Di  all  values  that  do  not  participate  in  a  solution  to  C. 

The  idea  is  that  the  removed  values  cannot  be  present  in  any  solution  to  the  considered  CSP.  We  can 
formalize  this  operation  by  means  of  the  following  proof  rule: 


HYPER-ARC  CONSISTENCY 

_ _ (C  ;  Xy  £  Dy,  .  .  .,Xn  £  Dn) _ _ 

{C  ,  Xy  £  Dy,  .  .  .,Xi-y  £  Dj_i ,  Xi  G  D'^,  Xi.^.y  £  Dj+i, .  .  .,Xn  £  Dn) 

where  C  is  a  constraint  on  the  variables  xy,. .  .,Xn,  i  £  [l-.n],  and 


D'i  {a  £  Di  \  3d  £  C  q  =  d[a;j]}. 

One  can  easily  show  that  a  CSP  is  hyper-arc  consistent  ift'  it  is  closed  under  the  applications  of  the  HYPER¬ 
ARC  CONSISTENCY  rule. 


Linear  inequalities  over  integers  Assume  that  the  domains  are  non-empty  intervals  of  integers,  written  as  [a..W, 
and  the  constraints  are  linear  inequalities.  For  the  constraints  of  the  form  x  <  y  we  can  apply  the  following 

_ {x<y,x£  [h..h^],y  £  [ly..h^]) _ 

{x<y  ]  x£  %..min{h^,hy  -  1)],^  G  [max{ly,l^  +  l),hj,]) 

The  idea  is  that  x  <  y  and  y  <  hy  imply  x  <  hy  —'l.  This  in  conjunction  with  x  <  implies  that 
x  <  min{hx,  hy  —  1),  and  analogously  with  the  variable  y. 

For  example,  this  rule  allows  us  to  transform  the  CSP 


(x  <  y  ;  a:  G  [50..200],j/ G  [0..100]) 

into 

(a:  <  2/ ;  X  G  [50..99],y  G  [51..100]> 

which  has  smaller  domains. 

The  rule  for  the  general  case  for  arbitrary  linear  inequalities  can  be  found,  e.g.,  in  Apt  (1998). 

Next,  consider  the  reduction  of  constraints.  We  illustrate  it  by  means  of  two  examples.  In  each  of  them  a 
new  constraint  is  introduced.  This  can  be  viewed  as  a  reduction  of  a  constraint.  Namely,  an  introduction  of 
a  new  constraint,  say  on  the  variables  X,  leads  to  an  addition  of  a  new  conjunct  to  the  conjunction  of  used 
constraints  on  X  (if  there  is  none,  we  can  assume  that  a  “universal”  true  constraint  on  AT  is  present)  The  new 
conjunction  is  then  semantically  a  subset  of  the  old  one. 
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Path  Consistency  This  example  deals  with  the  notion  of  path  consistency  introduced  in  Montanari  (1974).  Let 
us  recall  the  definition.  We  need  an  auxiliary  notion  first. 

Definition  2.  We  call  a  CSP  V  normalized  if  for  each  subsequence  X  of  its  variables  there  exists  at  most  one 
constraint  on  X  in  V. 

Given  a  normalized  CSP  and  a  subsequence  X  of  its  variables  we  denote  by  Cx  the  unique  constraint  on 
the  variables  X  if  it  exists  and  otherwise  the  “universal”  relation  on  X  that  equals  the  Cartesian  product  of  the 
domains  of  the  variables  in  X.  □ 

Every  CSP  is  trivially  equivalent  to  a  normalized  CSP.  Indeed,  for  each  subsequence  X  of  the  variables  of 
V  such  that  a  constraint  on  X  exists,  we  just  need  to  replace  the  set  of  all  constraints  on  X  by  its  intersection. 
Note  that  the  universal  relations  Cx  are  not  constraints  of  the  normalized  CSP. 

Given  a  subsequence  x,y  of  two  variables  of  a  normalized  CSP  we  introduce  a  “supplementary”  binary 
relation  Cy^x  defined  by 

Cy,x  ■—  i  (^)b)  £  Cx,y}- 

The  supplementary  relations  are  not  parts  of  the  considered  CSP  as  none  of  them  is  defined  on  a  subsequence 
of  its  variables,  but  they  allow  us  a  more  compact  presentation.  W’e  now  introduce  the  desired  notion. 

Definition  3.  We  call  a  normalized  CSP  path  consistent  if  for  each  subset  {x,y,z}  of  its  variables  we  have 

~  {(®)  b)  I  3c  ((a,  c)  £  Cx,z>  (c,  b)  £  Cz^yf}. 

□ 


In  other  words,  a  normalized  CSP  is  path  consistent  if  for  each  subset  {x,  y,  z}  of  its  variables  and  the  pair 
(a,  6)  G  Caj.j,  there  exists  c  such  that  (a,  c)  £  (7e,^  and  (g,  6)  £  C2,j,. 

We  now  characterize  this  notion  of  local  consistency  in  terms  of  rules.  In  the  rules  below  we  omit  the  domain 
expressions.  We  assume  here  that  x,  y,z  is  a  subsequence  of  the  variables  of  the  considered  CSP. 

PATH  CONSISTENCY  1 

tCx,yi  tSy,Z'i  Cx,z 

where  the  constraint  C'^^y  on  the  variables  x,  y  is  defined  by 

Cx,y  ■=  C!x,y  n  {{a,b)  I  3c  ((a,c)  6  Cx,z,  {b,c)  £  Cy,z)}, 

PATH  CONSISTENCY  2 

tSx,yi  Cy^Zl  Cx,z 

Cx,y,Cy^ziC'z.^^ 

where  the  constraint  C'^^^  on  the  variables  x,  jz  is  defined  by 

C'i.r  C'x.z  n  {(a,  c)  I  3b  ((a,  b)  £  Cx,y,  (b,  c)  £  Cy^z)}, 

PATH  CONSISTENCY  3 

Cx^yi  Cy^zi  Cx,z 
C'x,yi  Cy,zi  tSx,z 

where  the  constraint  ^  on  the  variables  y,  z  is  defined  by 

n{(6,c)  I  3a  ((a,  6)  €  Cx,y,ia,c)  £ 

One  can  show  now  that  a  normalized  CSP  is  path  consistent  iff  it  is  closed  under  the  applications  of  the 
PATH  CONSISTENCY  rules  1,  2  and  3.  . 
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Resolution  rule  This  last  exan^le  deals  with  (propositional)  clauses,  that  is,  disjunctions  of  literals.  Let  Ci  and 
C2  be  clauses,  L  a  literal  and  L  the  literal  opposite  to  L,  that  is  =  a;  and  x  =  -ix. 

Consider  now  the  following  proof  rule  called  the  resolution  rule: 

(Cl  V  L,C2  V  L-,V£) 

(Cl  VL,C2  VL,Ci  VC2  ;  V£) 

It  introduces  a  new  constraint,  the  clause  Ci  V  C2. 

In  general,  as  noticed  in  Dechter  &  van  Seek  (1997),  various  general  techniques  drawn  from  the  fields  of 
linear  alpbra,  linear  programming,  integer  programming,  and  automated  theorem  proving  can  be  explained  as 
a  reduction  of  constraints. 

The  above  examples  dealt  with  atomic  reduction  steps  in  which  either  a  domain  or  a  constraint  is  reduced. 
The  constraint  propagation  algorithms  deal  with  the  scheduling  of  such  atomic  reduction  steps.  In  particular, 
these  algorithms  should  avoid  useless  applications  of  these  atomic  reduction  steps. 

In  Apt  (1999a)  it  is  shown  that  the  constraint  propagation  algorithms  can  be  explained  as  instances  of  four 
algorithms  that  deal  with  chaotic  iteration.  This  allows  us  to  limit  the  presentation  of  these  algorithms  to  a 
specification  of  the  atomic  reduction  steps.  A  similar  work  on  this  subject  was  carried  out  by  Benhamou  (1996) 
and  Telerraan  &  Ushakov  (1996). 

The  examples  of  hyper-arc  and  path  consistency  illustrate  how  the  known  notions  of  local  consistency  can 
be  couched  in  the  proof  theoretic  framework  and  how  the  corresponding  well-known  constraint  propagation 
algorithms  can  be  automatically  derived  from  the  appropriate  proof  rules. 

The  other  two  examples  show  the  generally  of  this  proof  theoretic  framework.  This  suggests  that  the 
presentation  of  the  desired  constraint  propagation  algorithms  can  be  limited  to  either  a  specification  of  the 
desired  notion  of  local  consistency  or  to  a  presentation  of  the  appropriate  proof  rules.  In  both  situations  the 
proposed  proof  theoretic  framework  is  sufficiently  general  for  our  purposes. 


3  Example:  Boolean  Constraints 

Let  us  illustrate  now  the  above  account  of  constraint  programming  by  means  of  an  example.  It  will  clarify 
what  choices  one  needs  to  make  when  solving  specific  CSP’s.  These  choices  will  be  reflected  in  specific  decisions 
concerning  the  subsidiary  procedures  of  the  generic  Solve  procedure. 

Suppose  that  we  wish  to  find  all  solutions  to  a  given  Boolean  constraint  satisfaction  problem.  In  this  case 
the  constraints  are  identified  with  (the  solutions  to)  the  propositional  formulas  and  the  domains  are  subsets  of 

the  truth  set  represented  by  {0, 1}.  Then  we  could  consider  the  following  selection  of  the  procedures  discussed 
above. 

Preprocess 

We  bring  each  Boolean  constraint  to  one  of  the  following  forms: 

-  x  =  y, 

-  -'X  =  y, 

-  X  hy  =  z, 

-  xM  y  =  z. 

Consequently,  for  Preprocess  we  choose  the  transformation  rules  that  transform  each  Boolean  constraint 
into  a  set  of  constraints  in  the  above  form.  An  example  of  such  a  transformation  rule  is 

X  A  (f)  =  z 
xAy-z,^-y 

where  x,y,  z  are  Boolean  variables  and  where  is  a  Boolean  expression  that  does  not  contain  y. 

Happy 

We  choose  the  test:  all  solutions  have  been  found. 

Split 

We  use  the  labelling  rule  discussed  in  Subsection  2.3.  We  need  to  be,  however,  more  precise  as  this  rule  is 

parametrized  by  a  variable  the  choice  of  which  is  of  relevance,  and  by  a  value  the  choice  of  which  is  not  relevant 
here. 
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We  use  here  a  well-known  heuristic  according  to  which  the  variable  that  occurs  in  the  largest  number  of 
constraints  (the  “most  constrained  variable”)  is  chosen  first. 

Proceed  by  Cases 

We  want  to  find  all  solutions,  so  we  choose  here  the  backtracking  search. 

Constraint  Propagation 

Finally,  we  determine  the  actions  of  the  constraint  propagation  algorithm.  We  do  this  by  choosing  specific 
domain  reduction  steps.  They  are  based  on  the  simple  observation  that  for  the  Boolean  constraints  in  one  of  the 
forms  considered  in  the  definition  of  the  Prbi^rocess  procedure,  if  the  values  of  some  variables  are  determined 
then  values  of  some  other  variables  are  determined,  as  well.  For  example,  for  the  constraint  a:  A  y  =  z,  if  we 
know  that  2;  is  1  (i.e.,  true),  then  we  can  conclude  that  both  x  and  y  axe  1.  This  is  expressed  by  means  of  the 
following  rule: 

[xAy-Z]  X  £  Dx,y  £  Dy,z  e  {!}) 

{  ;  X  e  Dxn{l},y  £  Dyn{l],z  e  {1}) 

where  the  absence  of  the  constraint  a;  A  y  =  ^  in  the  conclusion  indicates  that  this  constraint  is  solved  (that  is, 
satisfied  by  all  combinations  of  domain  values). 

We  can  abbreviate  it  to  a  more  suggestive  form,  namely 

a;  A  y  =  z,  2;  =  1 -4- a:  —  1,  y  =  1. 

In  total  there  are  six  such  rules  for  the  constraint  x  Ay  —  z  and  twenty  rules  for  all  constraints  considered  in 
the  definition  of  the  PREPROCESS  procedure.  They  are  presented  in  Table  1.  The  resulting  proof  system  BOOL 
is  very  similar  to  the  one  discussed  in  Codognet  &  Diaz  (1996). 
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Table  1.  Proof  system  BOOL 


To  read  properly  such  formulas  it  helps  to  remember  that  0  and  1  are  domain  elements,  so  atomic  formulas 
of  the  form  a:  =  0  and  a;  =  1  are  domain  expressions  while  all  other  atomic  formulas  are  constraints. 

One  can  prove  (see  Apt  (19996))  that  this  proof  system  characterizes  the  notion  of  hyper-arc  consistency 
for  Boolean  constraints  in  the  sense  that  a  Boolean  CSP  is  closed  under  the  rules  of  BOOL  iff  it  is  hyper-arc 
consistent. 

This  completes  the  description  of  a  sample  procedure  using  which  we  can  find  all  solutions  to  a  Boolean 
constraint  satisfaction  problem.  From  this  presentation  it  is  clear  that  the  resulting  program  can  be  obtained  by 
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putting  together  various  predefined  components  and  by  limiting  the  programming  process  to  the  specification 
of  the  rules  that  constitute  the  Preprocess  procedure  and  to  the  presentation  of  the  proof  system  BOOL. 


4  Concluding  Remarks 

In  the  above  discussion  many  aspects  of  constraint  programming  have  been  omitted.  Still  we  hope  that  this  brief 
introduction  sheds  some  light  on  the  subject  and  that  it  provides  some  insights  into  the  claim  that  constraint 
programming  is  amenable  to  component-based  programming. 
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Abstract.  The  paper  describes  a  problem  of  multi-agent  path  planning  in  environment  with  obstcicles. 
Novel  approach  to  multi-agent  optimal  path  planning,  using  graph  representation  of  environment  models  is 
described.  When  planning  the  path  of  each  robot,  the  graph  model  of  environment  is  dynamically  changed 
for  path  correction  and  collision  avoidance.  New  algorithm  applies  changes  of  robots’  paths  and  speeds  to 
avoid  collisions  in  multi-agent  environment. 


1  Introduction 

Problems  of  multi-agent  robot  systems  control  have  got  significant  importance.  Each  multi-agent  robot  system 
has  some  transport  subsystem,  which  consists  of  several  mobile  robots.  The  problem  of  controlling  such  mobile 
robot  group  can  be  divided  into  two  main  parts: 

—  Optimal  global  (general)  task  decomposition  into  subtasks,  and  their  optimal  distribution  between  separate 
robots  in  the  group. 

—  Path  planning,  control  and  movement  correction  for  each  mobile  robot. 

New  approach  to  path  planning  and  motion  programming  for  mobile  robots  is  proposed.  The  method  is 
based  on  graph  optimization  algorithms.  Novelty  of  the  developed  multi-agent  path  planning  algorithm  is  as 
follows: 

—  All  mobile  robots  are  considered  as  dynamic  obstacles. 

—  Graph  representation  of  common  environment  models  is  used  for  path  planning. 

—  Each  edge  of  the  graph  has  two  weights:  distance  and  motion  time  (speed). 

—  Weights  of  edges  can  be  modified  during  path  planning. 

—  The  quickest  path  is  planned  (time  optimization).  , 

—  Expert  rules  for  speed  and  path  correction  are  synthesized  to  provide  collision  avoidance. 

The  algorithm  is  formulated  in  terms  of  the  optimal  find-path  problem  on  a  graph,  where  the  graph  edges 
axe  labelled  with  some  values.  It  is  usually  possible  to  transform  common  environment  models  (e.g.  vector  or 
grid  model)  to  the  corresponding  graph  representation.  Thus,  the  algorithm  can  be  applied,  for  example,  on 
visibility  graphs  and  grid  environment  models. 

2  Background 

The  problem  of  path  planning  for  various  types  of  mobile  robots  was  Widely  investigated  by  many  researchers  [5, 
8-11],  but  almost  all  of  them  consider  the  problem  of  path  planning  for  a  single  mobile  robot.  The  problem  of 
path  planning  for  a  group  of  mobile  robots  was  investigated  in  [10,11],  but  the  proposed  algorithms  did  not 
provide  path  optimality  in  any  sense.  In  [6]  there  was  introduced  an  approach  to  control  a  group  of  mobile 
robots  by  means  of  the  global  task  decomposition  into  several  subtasks,  with  non-intersected  paths  of  the  robots. 
This  is  not  possible  for  many  practical  tasks,  like  manufacturing,  traffic  control,  etc.  Therefore,  a  problem  of 
adaptation  of  known  optimal  path  planning  algorithms  for  multi-agent  robot  systems  exists  [1,2]. 

Planning  mobile  robot  motions  in  a  multi-agent  robot  system  has  a  number  of  peculiarities  and  some 
additional  difficulties.  They  are  related  to  necessity  of  taking  into  account  not  only  possible  obstacles  (including 
unknown  ones)  in  a  working  space,  but  also  movement  of  other  robots,  while  planning  the  path  of  each  agent- 
robot.  It  seems  logical  to  divide  the  problem  of  path  planning  and  control  of  mobile  robots-agents  in  a  working 
zone  into  two  subproblems. 
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-  Path  planning  and  optimization  for  each  agent-robot  individually,  taking  into  account  other  robots  move¬ 
ment.  This  problem  can  be  solved  by  modifying  algorithms  of  path  planning  and  optimization  in  an  envi¬ 
ronment  with  obstacles.  At  this  stage,  full  knowledge  of  the  environment  is  supposed  (i.e.  the  environment 
does  not  contain  unknown  obstacles). 

—  Unforeseen  collisions  avoidance  and  the  planned  paths  correction  in  case,  when  information  about  the 
environment  is  incomplete,  or  robot  paths  deviate  from  the  planned  ones.  There  are  two  basic  alternatives 
to  solve  this  problem.  First  is  to  correct  the  paths  by  means  of  various  path  local  correction  algorithms. 
Shortage  of  this  approach  is  non-optimal  agent-robot  motions.  The  second  method  is  complete  or  local- 
optimal  path  re-planning,  when  new  obstacles  discovered  or  collisions  occurred. 

It  should  be  mentioned,  that  cooperation  between  individual  agent-robots  is  necessary  to  solve  the  path  planning 
and  optimization  problem.  Each  agent-robot  has  to  share  information  about  its  planned  path  and  actual  motions 
with  other  agent-robots.  Maintaining  the  planned  paths  database  and  motion  coordination  could  be  performed 
by  the  special  agent-supervisor.  The  agent-supervisor  maintains  information  about  environment  and  each  agent- 
robot  motions.  Information  about  environment  is  collected  by  agent-robots,  equipped  with  sensors.  The  path 
planning  system  of  each  agent-robot  can  use  information  from  the  agent-supervisor.  In  some  cases  the  agent- 
supervisor  plans  paths  for  all  the  agents-robots  and  transmits  the  planned  paths  to  them. 

Solution  of  the  second  problem  would  be  more  reasonable  to  be  assigned  to  local  control  systems  of  agents- 
robots,  thus  the  accident-free  realization  of  the  robots  tasks  is  ensured  even  in  case  of  malfunctioning  commu¬ 
nication  of  the  agents.  To  solve  this  problem,  an  agent-ro|)ot  should  have  its  own  sensor  system,  which  must 
be  able  to  provide  distinguishing  static  obstacles  and  moving  robots.  Besides,  sensor  systems  of  robots  can  be 
applied  to  correction  of  the  environment  model  for  more  accurate  path  planning. 

3  Environment  Models 

There  is  a  lot  of  widely  known  environment  models,  for  example,  grid  (occupancy  cell),  vector  (obstacles  are 
represented  by  polygons),  graph  (visibility  graph,  Voronoi  diagram,  etc.)  [3]  and  their  modifications.  Special 
types  of  environment  model,  for  example,  analytic-predicate,  semantic,  etc.,  exist  as  well  [1, 12]. 

Each  environment  model  has  certain  advantages  and  disadvantages  for  path  planning  purposes,  for  instance: 
Grid  model  is  simple  to  be  used,  corrected  and  updated  with  data,  gathered  by  different  robots.  But  it  requires 
high  memory  expenses,  it  also  has  high  data  redundancy  and  lack  of  accuracy.  Some  of  these  drawbacks  can  be 
eliminated  by  using  more  comprehensive  grid  model  [8]. 

Vector  models  feature  high  precision,  low  memory  expenses,  but  it  is  difficult  to  plan  a  path,  using  this  type 
of  models,  it  is  also  difficult  to  update  the  environment  model  with  data  from  robots’  sensor  systems,  since 
sensor  information  is  usually  presented  in  discrete  form  and,  hence,  needs  to  be  transformed  into  the  vector 
form. 

Graph  models  are  more  suitable  for  path  and  motion  planning  problems.  As  a  rule,  graph  model  onlv 
consists  of  possible  paths,  i.e.  information  about  obstacles  is  excluded  during  the  graph  constructing.  Grid 
and  Vector  models  can  be  mapped  onto  the  graph  model.  There  are  known  various  algorithms  for  solving 
optimization  problem  on  the  graph,  for  example,  Dijkstra  algorithm.  A*,  D*-algorithm  [5],  etc.  The  possible 
paths  in  vector  environment  model  can  be  represented  by  a  visibility  graph.  The  visibility  graph  is  a  graph, 
which  nodes  repr^ent  vertices  of  polygonal  obstacles,  and  its  edges  represent  straight  possible  paths,  connecting 
the  obstacle  vertices,  i.e.  lines  of  “visibility”.  Once  the  static  graph  is  constructed,  target  and  starting  points 
are  added  and  the  visible  edges,  connecting  them  with  other  graph  nodes,  are  computed.  To  plan  paths,  graph 
model  will  be  further  used.  Graph  of  possible  paths  can  be  obtained  from  both  vector  and  grid  environment 
models.  Moreover,  graph  of  admissible  paths  can  be  constructed  on  the  base  of  agent-robots’  experience  of 
motion.  Information  about  agent-robots’  motions  can  be  stored  separately,  or  in  the  graph  nodes. 

In  summary,  the  advantages  of  using  a  visibility  graph,  or  graph  of  possible  paths  fpr  motion-planning  are  in 
fact,  that  it  is  a  simple,  well-understood  method,  which  yields  optimal  paths  in  2D,  or  3D  configuration  space. 

4  Graph  Environment  Model 

The  graph  environment  model,  used  for  multi-agent  optimal  path  planning  is  described  below.  Points  (places) 
in  the  environment  and  admissible  (possible)  paths  between  them  are  represented  by  the  graph,  nodes  of  which 
represent  certain  places  in  the  environment  and  edges  represent  admissible  paths.  Each  edge  of  the  graph  has  a 
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weight,  that  is  adequate  to  path  length,  travel  time,  or  difficulty  of  traveling  etc.  between  corresponding  nodes. 
Note,  that  the  graph  by  creation  only  consists  of  admissible  paths. 

Let  us  consider  a  graph  G{V,  E)  with  M  nodes.  All  nodes  are  numbered.  Each  node  i  has  M*  >  1  adjacent 
nodes  (vertices)  *1,12,...,  iui  •  Besides,  all  graph  nodes  are  characterized  with  a  weight  Wi.  Weight  Wi  of  a  node 
i  (i  =  1,2,  corresponds  to  the  value  of  minimized  functional  (for  example,  distance,  or  motion  time). 

To  each  edge  of  the  graph,  connecting  nodes  i  and  j,  there  are  assigned  two  characteristics:  Sij  —  distance  in 
space  between  these  two  nodes  and  Uj  —  motion  time,  depending  also  on  motion  speed.  In  summary,  any  such 
graph  possesses  the  properties,  as  follows; 

Each  Node  of  graph  is  characterized  by: 

1.  Coordinates  of  a  point  in  the  environment  space. 

.2.  Value  Wi  of  functional  to  be  minimized  (distance,  time,  etc.). 

3.  Set  of  adjacent  nodes  I’l,  12,  •  •  ■ ,  • 

4.  Additional  characteristics  needed  for  multi-agent  path  planning,  such  as  set  of  agent-robots,  moving  through 
the  node,  and  the  corresponding  set  of  time  moments. 

Each  Edge  of  graph  is  characterized  by:  - 

1.  Distance  Sii  between  nodes  i  and  j. 

2.  Weight  of  the  edge  lij  corresponds  to  time  of  motion  from  node  i  to  j.  This  value  is  variable  and  may  be 

changed  while  planning  the  path.  ^ 

3.  Additional  characteristics.  For  example,  the  edge  may  have  two  different  weights  lij  and  Iji,  that  depend  on 
direction  of  motion  between  i  and  j.  It  allows  to  simulate  3-D  environment  or  bi-directional  roads. 

5  Multi-agent  path  planning  algorithm 

Let  us  introduce  some  definitions:  the  shortest  path  is  a  path  of  minimal  length,  the  quickest  path  is  a  path  of 
minimum  motion  time. 

Let  there  is  required  to  find  a  node  sequence,  which  denotes  the  shortest  path  from  the  start  point  to  the 
target  point.  Before  the  path  planning,  all  weights  kj  of  the  graph  edges  have  to  be  initialized  as  follows: 


where  V  is  an  average  speed  of  the  agent-robot.  This  is  done,  assuming  that  robots  move  along  the  paths  with 
some  average  (economy)  speed,  and  to  take  into  account  possibility  of  braking  and  acceleration  as  well. 

The  weights  of  the  graph  nodes  must  be  initialized  with  a  maximum  possible  value  00.  The  start  node  must 
be  initialized  by  the  start  time  value  Wo  =  to-  According  to  known  edge  weights,  and  using  one  of  optimization 
algorithms,  for  example  Dijkstra’s  algorithm,  the  shortest  path  is  found  then.  During  path  planning,  weights  of 
nodes  change  and  get  equal  to  the  moments  of  time,  at  which  the  agent-robot  passes  through  these  nodes.  Note, 
that  in  fact,  taking  into  account  the  above  described  initialization  method,  the  algorithm  finds  the  quickest 
path,  but  in  case  of  one  path  planning,  the  shortest  and  the  quickest  paths  are  the  same. 

When  planning  paths  of  several  robots,  let  us  consider  the  path  of  each  robot  not  only  in  environment 
Cartesian  space  (as  it  was  done  for  a  single  robot  path  planning).  Let  us  plan  the  path  in  the  time-space 
continuum  in  order  to  take  into  account  other  robots  movement.  Such  approach  allows  to  avoid  collision  of 
separate  agent-robots,  simultaneously  moving  in  the  time-space  continuum.  Hence,  paths  are  planned  not  in  2D 
planar  environment,  but  in  3D  time-space  environment,  taking  into  account  movement  of  all  other  agents-robots. 
Let  us  note  here,  that  if  one-agent  path  planning  is  performed  in  3D  Cartesian  environment,  the  multi-agent  path 
planning  is  performed  in  4D  space  —  with  concern  of  time  (schedule  of  robots  movement).  The  described  below 
algorithm  uses  this  approach  and  plans  agents-robots  paths  sequentially  (path  by  path),  and  when  planning  the 
next  robot  path,  all  already  planned  paths  are  taken  into  account  to  eliminate  collisions. 

According  to  the  described  approach,  the  main  differences  of  the  developed  multi-agent  optimal  path  planning 
algorithm  from  the  one-agent  one  are  as  follows:  , 

-  to  each  graph  node  i  {i  =  1,2,..., M)  there  is  assigned  not  only  its  weight  Wi,  but  the  node  additionally 
stores  two  sets:  moments  of  time,  when  other  agents-robots  move  through  this  node  i  (let  tji  is  a  time  when 
robot  j  passes  through  node  i),  and  IDs  of  these  agents-robots  as  well. 

-  The  graph  (in  particular,  weights  of  the  edges)  can  be  changed,  when  planning  a  path  of  each  robot  to  avoid 
collisions. 
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For  multi-agent  path  planning  the  one-agent  path  planning  algorithm  must  be  supplied  with  a  number  of 
expert  rules,  which  provide  collision-free  planning.  Collision  avoidance  is  performed  by  means  of  the  graph 
correction  —  changing  edge  weights.  This  results  either  in  path  Correction  {a  robot  is  forbidden  to  move  on  the 
edge,  occupied  by  another  robot),  or  change  of  robot’s  speed  (robot  is  forced  to  move  faster,  or  slower  on  some 
edges  in  order  to  free  up  the  way  for  others,  the  paths  of  which  are  planned  earlier  and,  hence,  already  known). 
Besides,  if  D*-algorithm  is  used  as  a  basic  path  optimization  algorithm,  the  distance  between  two  nodes  can 
be  changed.  Changing  the  distance  corresponds  to  environment  model  correction. 

Initialization  of  graph  node  weights  Wi  (i  =  1,2,  ...,M)  is  the  same  as  in  the  one-agent  path  planning 
algorithm,  and  it  is  performed  before  each  robot  path  planning.  When  planning  a  path  for  any  robot,  graph 
node  weights  are  changed  just  as  in  the  one-agent  path  planning  algorithm: 


r  Wi+iuj,if(Wi+[u,)<Wi, 


(2) 


The  only  difference  is  that  this  rule  is  supplied  with  expert  rules  of  avoiding  collisions  in  the  graph  nodes,  which 
correspond  to  crossroads,  and  expert  rules  of  avoiding  collisions  on  the  graph  edges,  which  correspond  to  the 
straight  roads  (we  assume  one-way  simultaneous  movement,  i.e.  no  two  robots  can  mbve  simultaneously  on  the 
same  graph  edge  in  different  directions). 


5.1  The  Expert  Rules 


1.  Avoiding  collisions  in  the  graph  nodes  (crossroads) 

if  Wi  -f  la-  =  tki- ,  (A:  =  1, 2, . . . ,  n),  where  n  is  a  number  of  robots, 

then  lii^  =  liij  -f  e,  where  s  is  a  value,  that  defines  minimum  time  interval  between  different  robots  passing 
the  same  crossroads.  This  value  must  provide  safe  crossroads  passage.  Hence,  it  depends  on  robot  sizes  and 
speeds.  Weight  Wi.  of  node  ij  is  computed  then  according  to  formulae  (2).  This  means  the  increase  of  time 
of  the  robot  motion  on  the  graph  edge  from  node  i  to  ij  by  £  time  units,  and  corresponds  to  the  robot  speed 
change.  The  speed  is  piece-wise  constant  on  the  path,  and  is  computed  for  each  edge,  connecting  nodes  i 
and  j  as 


V-  -  =  ^ 

Vij  —  J 

H'i 


(3) 


2.  Avoiding  collisions  on  the  graph  edges  (straight  roads) 
if  (W,  <  tki)  A  [{Wi  -I-  la-)  <  tkij],  (k  =  1,2, . . .  ,n),  then 

if  tki  >  tkij ,  then  this  is  a  case,  when  two  robots  will  move  in  opposite  directions,  and  the  robot,  which 
path  is  being  planned,  will  pass  through  the  edge  before  robot  k.  No  collision  happens,  hence,  change  of  the 
edge  weight  is  not  necessary.  The  weight  of  the  next  node  Wj.  is  computed  as  (2). 

else  if  {tki  <  tkij)  A  ^tki  <  ^  collision  is  possible:  robot  k  will  follow  the 

robot,  which  path  is  being  planned,  and  hit  it  on  the  edge.  To  avoid  collision,  it  is  necessary  to  change  the 
edge  weight  for  the  current  robot  (i.e.  to  change  the  motion  time  by  increasing  speed): 


h 


{Wi  -  4,.  -  e){tki.  -  tki) 

iki  tki^  £ 


(4) 


Then  the  node  weight  Wi.  is  computed  according  to  (2). 

else  robot  k  will  follow  the  robot,  which  path  is  being  planned,  but  its  speed  is  insufficient  to  hit  the 
currently  computed  robot  on  the  edge.  Then  the  edge  weight  is  not  to  be  changed,  and  the  node  weight  Wi. 
is  computed  as  (2)  j 

if  {Wi  >  tki)  A  [{Wi  -I-  lii.)  >  tki^],  {k  —  1,2,...,  n),  then 

if  tki  >  tkij ,  then  this  is  a  case,  when  two  robots  move  in  opposite  directions,  and  robot  k  wdll  pass  through 
the  edge  earlier,  than  the  robot,  path  of  which  is  being  planned,  drives  onto  the  edge.  There  is  no  need  in 
this  case  to  change  the  edge  weight,  since  no  collision  is  to  occur.  Then  the  node  weight  Wi.  is  computed 
as  (2).  ^ 

'liij 


else  it  {tki  <  tkij)  A  tki 


< 


< 


tkij  5  then  collision  is  to  happen:  the  robot,  which  path 


^  ^kij  tki  liij  -  J  -  _  ,  ^ 

is  being  planned,  will  follow  robot  k  on  the  edge,  and  hit  it  due  to  high  speed.  To  avoid  the  collision,  it  is 
necessary  to  decrease  speed  of  the  robot,  which  is  being  computed,  i.e.  to  increase  its  time  of  motion  on  this 
edge  according  to  (4),  then  the  node  weight  is  determined  as  (2). 
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else  the  robot,  which  path  is  being  planned  has  insufficient  speed  to  catch  and  hit  robot  k  before  the 
crossroads.  The  node  weight  Wij  then  is  computed  as  (2). 
if  (Wi  <  tfci)  A  [(Wi  +  >  ifci,],  (fc  =  1, 2, n),  then 

if  tki  <  tkij ,  then  collision  is  possible:  robot  k  will  follow  and  hit  the  robot,  which  path  is  being  planned, 
before  the  crossroads.  To  avoid  the  collision,  the  speed  of  the  current  robot  obviously  should  be  increased. 
For  this  to  be  achieved,  the  edge  weight  is  to  be  changed  according  to  (4) ,  then  the  node  weight  is  computed 
as  (2). 

else  if  tki  >  tkij )  then  collision  can  not  be  avoided:  robot  k  will  have  been  moving  on  the  edge  in  the 
opposite  direction,  when  the  robot,  which  path  is  being  planned,  drives  onto  the  edge.  To  avoid  collision, 
the  motion  through  the  edge  from  node  i  to  node  ij  must  be  forbidden  for  the  current  robot.  To  reach  this 
goal,  let  us  change  the  weight  of  the  edge  as  follows: 

hij  —  00  .  (5) 

Then  the  node  weight  Wi^  is  computed  according  to  (2).  Let  us  note,  that  at  further  path  constructing 
this  edge  will  not  be  included  into  the  path  due  to  its  infinite  weight.  Therefore  this  type  of  collisions  is  also 
avoided. 

if  {Wi  >  tki)  A  [(Wi  +  liij )  <  tkij],  (A:  =  1, 2, ... , n),  then  tki  <  tkij  and  the  collision  is  possible  (it  is  the 
only  possible  case,  since  luj  >  0  ):  the  robot,  which  path  is  being  planned,  will  follow  and  hit  robot  k  before 
the  crossroads.  To  avoid  the  collision,  it  is  necessary  to  change  the  edge  weight  according  to  (4),  and  then 
the  node  weight  is  computed  as  (2). 

6  Summary 

Using  graph  of  possible  paths  makes  developed  algorithms  of  robot  path  planning  abstract  to  environment 
model,  thus  improving  their  application  capacity. 

These  algorithms  provide  global  optimality  while  path  planning  according  to  various  given  optimum  criteria: 
least  motion  time,  least  path  length,  etc. 

Multi-agent  path  planning  algorithm  also  provides  robots  collision  avoidance.  That  algorithm  automatically 
plans  safe  robot  paths,  which  do  not  intersect  each  other  in  time-space  continuum.  Simulation  results  approve 
effectiveness  of  synthesized  algorithms. 

Finally,  let  us  note,  that  the  described  multi-agent  algorithm  implies  sequential  path  planning  for  each  of 
robots  (path  by  path),  and  when  planning  the  next  robot  path,  all  already  planned  paths  are  taken  into  account 
to  eliminate  collisions.  Therefore,  path  of  the  first  robot  in  the  sequence  is  planned  with  the  one-agent  algorithm, 
path  of  the  second  robot  is  planned  with  concern  of  the  first  robot’s  path,  when  planning  path  of  the  third 
robot,  paths  of  first  two  are  taken  into  account,  etc.  And  the  described  algorithm  provides  optimality  of  all 
planned  paths.  It  means,  that  currently  planned  path  is  optimal  of  all  possible  at  this  stage.  However,  the  paths 
(and,  hence,  their  lengths  and  motion  times)  depend  on  the  order  of  planning,  i.e.  there  is  a  question,  which 
robot  path  should  be  planned  first,  which  is  to  be  second,  etc.  This  problem  is  not  significant,  if  relation  of 
possible  paths  quantity  on  the  graph  to  the  number  of  robots  is  big  enough.  But  if  the  described  expert  rules 
correct  the  graph  (edge  weights)  too  frequently  while  path  planning,  then  the  choice  of  the  right  sequence  of 
robots  for  path  planning  may  have  significant  influence  on  the  general  robot  team  performance.  This  problem 
is  still  open,  and  it  is  a  question  of  a  separate  research  to  investigate  it. 
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Abstract.  The  paper  describes  an  experimental  system  for  understanding  short  texts  from  a  limited 
problem  domain  (weather  forecast  telegrams  written  in  Russian).  A  semantics-oriented  and  text  type 
specific  approach  to  analysis  is  proposed  which  gives  preference  to  lexical-semantic  and  topical  coherence 
mechanisms  in  their  relation  to  the  domain  structure.  The  system  is  implemented  with  both  classical  means 
for  knowledge  representation  and  processing  and  methods  of  object-oriented  and  agent-based  technique. 

1  Introduction 

The  paper  describes  an  experimental  system  for  understanding  real  short  texts  from  a  limited  problem  domain, 
cf.  previous  work  in  [1,2].  The  goal  of  the  analysis  is  to  explicate  the  informational  content  of  the  input  text 
by  a  semantic  network  (tree),  which  is  used  as  a  basic  knowledge  representation  language  suitable  for  further 
transforming  to  represent  information  in  any  other  terms.  The  choice  of  formal  means  and  the  underlying 
linguistic  approach  are  based  upon  the  following  principles:  a)  the  understanding  system  is  both  the  domain  and 
genre  (text  type)  specific;  b)  the  analysis  procedure  is  semantics-oriented;  c)  information  of  different  linguistic 
levels  (lexical,  syntactic,  semantic,  pragmatic)  is  processed  simultaneously  due  to  the  object-oriented  paradigm 
using  class  hierarchy  with  multiple  inheritance;  d)  special  means  to  represent  linguistic  indeterminate  units  are 
utilized;  e)  the  declarative  descriptions  with  a  system  of  agents  provide  a  local  bottom-up  parsing  procedure. 

The  presented  experimental  system  is  implemented  with  the  help  of  the  software  environment  SemP-A  that  is 
an  advanced  version  of  SemP-TAO  system  [3].  SemP-A  is  based  on  an  integrated  knowledge  representation  model 
which  combines  both  classical  means  for  knowledge  representation  and  processing  (such  as  frames,  semantic 
networks  with  binary  relations  etc.)  and  methods  of  object-oriented  and  constraint  programming.  Important 
features  of  the  environment  are  the  ability  to  operate  with  objects,  that  can  have  attributes  with  imprecisely 
defined  values,  and  the  utilization  of  the  agent-based  technique  as  a  main  means  for  definition  of  logical  inference 
and  data  processing. 

Each  agent  reacts  only  to  related  events  (e.g.  appearance  of  new  objects  of  certain  class  or  changing  values 
of  their  attributes  or  setting  new  relations  between  objects).  Actuation  of  the  agent  can  lead  to  creating  new 
objects  or  changing  state  of  the  existing  ones.  This,  in  turn,  causes  activation  of  other  agents  associated  with 
the  new  or  modified  objects  and  so  on.  Unlike  the  production  systems  that  use  an  expensive  pattern-matching 
routine,  the  activation  of  agents  is  based  on  the  associative  event-driven  mechanism  that  significantly  increases 
efficiency  of  the  inference  and  control  processes. 

2  Text  corpus  and  problem  domain 

The  texts  under  consideration  are  weather  forecast  telegrams  sent  by  local  forecasters  to  the  central  meteoro¬ 
logical  offices  {M-texts).  An  example  of  M-text  is  given  below  in  literal  translation  from  Russian: 

weather  tomsk  region  19/08/98= 

variable  cloudiness  in  morning  local  fogs  over  south  parts  locally  small  short  rains  thunderstorms  wind 
south  south-west  7-12  m/s  temp  at  night  8-13  at  day  time  8-23  tomsk  night  10-12  day  21-23= 

An  M-text  contains  a  sequence  of  prognostic  statements  with  parametric  semantics  (an  “object  -  parameter 
-  value”  scheme).  The  estimations  are  given  in  terms  of  parametric  Features  grouped  around  meteorological 
Elements  (Precipitation,  Cloudiness,  WeatherPhenomena,  Wind,  Temperature,  Inflamability)  within  topically 

*  This  work  is  supported  by  Russian  Foundation  for  Basic  Research  (grant  N  99-01-00495) 
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coherent  text  fragments.  Each  topical  fragment  contains  a  sequence  of  estimations  for  the  same  Element.  The 
correspondence  between  Elements  and  their  Features  is  represented  by  the  Element-Feature  relation,  the  third 
argument  of  the  relation  presenting  basic  parameters  of  the  Element; 

Element-Feature(  Element:  “Wind”,  Features:  {  “WindDirection” ,  “WindVariation” , 

“WindSpeed”,  “WindGust”},  DefaultFeatures:  “WindDirection”,  “WindSpeed”). 

Estimations  axe  time-  and  site-specific,  i.e.  they  are  made  with  respect  to  certain  Temporal  and  Locative 
objects.  The  territory  and  the  date  mentioned  in  the  heading  part  of  the  text  arc  basic  Loc  and  Temp  objects 
of  the  domain.  The  objects  of  estimation  in  elementary  statements  are  related  to  the  basic  Loc  and  Temp 
objects  as  their  parts:  e.g.  LocValue  local  and  TempValue  in  morning  in  the  fragment  in  morning  local  fogs. 
Circumstantial  Values  may  be  implicit  in  the  fragment  and  are  in  this  case  recovered  from  the  previous  context; 
e.g.  over  south  parts  locally  small  short  rains  \  thunderstorms. 

The  output  semantic  representation  of  the  topical  fragment  wind  south  south-west  7-12  m/s  from  the  example 
above  is  given  in  section  5,  Fig.  4. 


3  Approach  to  text  understanding  , 

Our  approach  to  text  understanding  takes  into  account  not  only  the  domain  structure  but  the  text  pragmatics 
as  well.  The  telegram  genre  causes  main  peculiarities  of  the  text  corpus.  Texts  are  extremely  concise  -  they 
are  written  in  “telegraphic  style”.  On  the  one  hand,  the  semantic  units  (Elements,  Features,  Loc  and  Temp 
Values)  are  reduced  as  they  can  be  easily  recovered  due  to  the  strong  semantic  and  topical  coherence  and  regular 
word  order.  On  the  other  hand,  grammatical  and  syntactic  elements  are  regularly  omitted  (lack  of  prepositions, 
conjunctions,  or  even  inflexions).  Means  of  text  segmentation  are  absent  (there  are  no  punctuation  marks  and 
capital  letters).  Abbreviations  are  widely  used.  Texts  bear  a  lot  of  mistakes  as  a  result  of  their  spontaneous 
production. 

Previously,  our  experiments  in  different  problem  domains  [1]  involved  local  morphological  and  syntactic 
processing.  The  specificity  of  the  M-text  corpus  results  in  a  strong  semantic  bias  of  our  approach  to  analysis. 
According  to  it,  lexical  semantics  of  words  and  word  collocations  is  defined  in  terms  of  “orientations”  as  pointers 
to  the  domain  system  of  concepts.  The  semantic  orientation  indicates  a  set  of  Features  that  can  be  represented 
by  a  lexeme  on  the  surface  level.  The  topic  orientation  relates  a  lexeme  to  the  set  of  Elements  whose  description 
admits  this  lexeme.  For  example,  the  vocabulary  unit  variable  is  the  Value  of  ”  Cloud  Amount”  or  ’’WindDirec¬ 
tion”  Features  and  topically  corresponds  to  ’’Cloudiness”  or  ’’Wind”  Elements.  This  information  is  stored  in 
the  slots  Orientation  and  TopicOrientation  of  the  vocabulary  entry  of  the  lexeme. 

The  semantics-oriented  approach  admits  processing  syntactic  non-regularities  resulting  in  proper  output  se¬ 
mantic  structures.  Several  types  of  semantic  units  (features,  values,  locations,  etc.)  that  appear  in  text  fragment 
under  analysis  are  combined  into  topical  and  semantic  structures  using  orientations  and  word  order  information. 
Topical  mechanisms  provide  the  recovery  of  reduced  semantic  objects. 


4  Class  hierarchy 

Fig.  1  shows  a  part  of  our  class  hierarchy  and  illustrates  interaction  between  lexical  units  and  concepts  of  the 
problem  domain.  The  hierarchy  takes  into  account  the  peculiarities  of  the  text  corpus:  it  lacks  classic  grammar 
classes  (no  verbs,  nouns,  etc.  and  no  morphological  characteristics).  The  base  class  Object  has  the  only  slot 
State  with  two  possible  values:  “working”  means  that  object  is  to  be  processed  and  “workedmut”  means  that 
the  object  is  no  longer  subject  to  any  further  processing. 

The  lexical  hierarchy  includes  classes  for  words,  numbers  and  signs.  The  base  class  LexObject  contains 
common  lexical  information  for  the  vocabulary  look-up.  A  chain  of  LexObjects  is  produced  by  a  special  LexSe- 
quence  relation. 

The  text  hierarchy  is  also  reduced,  as  there  are  no  paragraphs,  sentences  and  clauses.  The  only  text- 
structure  class  is  Topic  used  in  the  process  of  decomposition  of  the  input  chain  into  the  sequence  of  topically 
coherent  fragments.  SemWord  objects  are  related  to  Topic  by  a  special  Topical  relation. 

The  semantic  hierarchy  corresponds  to  lexical  level  of  the  domain  concepts.  SemObjects  are  characterized 
with  orientation  slots.  SemWords  are  elements  of  the  future  semantic  tree  bound  with  SemTree  relations. 
The  auxiliary  words  (AuxWord)  are  opposed  to  the  SemWord  class  as  they  serve  to  modify  meanings  or  even 
to  refine  classes  of  SemWords  but  are  never  present  in  the  resulting  structure. 
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Fig.  1.  Class  hierarcliy 


5  Agents  and  analysis  procedure 


The  analysis  procedure  is  performed  by  a  set  of  agents,  which  may  be  classified  according  to  their  functions  in 
the  process. 

The  first  group  of  agents  interacts  with  the  input  chain  to  execute  the  lexical  processing.  Agents  react  to 
the  current  portion  of  the  chain,  delimit  and  create  LexObject  nodes,  refine  their  classes  (LexSigns,  LexNumbers 
and  Lex  Words),  fill  their  slots  and  insert  them  into  the  network.  A  special  agent  performs  the  vocabulary  look-up 
for  class  and  slot  values  information.  The  LexSequence  relation  joins  the  node  being  inserted  into  the  network 
to  the  previous  one. 

The  agents  of  the  second  group  perform  the  presemantic  processing.  They  react  to  the  appearance  of 
instances  of  Number  or  AuxWord  classes.  The  AuxWord  subclasses  require  different  tj^pes  of  processing  and 
their  contribution  may  be  different.  For  example.  Preposition  with  locative  orientation  serves  to  disambiguate 
words  like  west  and  to  refine  its  class  as  a  LocValue  (over  west  regions  vs.  wind  west).  Fig.  2  presents  the 
results  of  lexical  and  presemantic  analysis  for  the  fragment  wind  south  south-west  7-12  m/s.  The  collocations 
have  been  assembled,  Number  orientation  specified,  interval  composed  and  refined  as  NumericValue. 


L«xSequeTic^  — - - - 

— - - - V- 

vihvl  snnih  1  sciiih  -  ve.Kt  j 

Element  Velue  \  Collncntion  WordScparator  Value  / 


Fig.  2.  Lexical  and  presemantic  processing 


The  third  group  of  agents  realizes  the  topical  analysis.  Agents  simulate  the  left-to-right  “reading”  of  the 
lexical  chain,  interact  with  nodes  of  the  SemWord  class ,  the  AuxWord  nodes  being  simply  passed  by  in  case  their 
states  are  “worked-out”  (otherwise  the  topical  processing  stops  and  waits  until  the  nodes  are  presemantically 
processed).  The  topical  relation  is  created  between  the  ’’working”  Topic  and  a  SemWord  node  provided  that 
their  TopicOrientation  values  conform.  The  topical  shift  (creation  of  a  new  Topic  node)  may  be  provoked  by 
a  new  SemWord  if  its  TopicOrientation  does  not  agree  with  that  of  the  ’’working”  Topic,  e.g.  thunderstorms  \ 
wind  south  south-west  7-12  m/s.  Circumstantial  Sem Words  provoke  a  subtopic  hypothesis  (text  fragment  with 
a  more  precise  description  of  the  same  Element)  that  may  be  later  rejected.  Fig.  3  demonstrates  the  results 
of  topical  analysis  for  our  example:  the  new  Topic  node  has  been  generated  on  meeting  the  Element  node  and 
further  bound  with  SemWord  nodes  by  Topical  relations. 

The  fourth  group  of  agents  performs  the  semantic  analysis,  which  involves  three  types  of  actions.  Several 
agents  deal  with  specification  of  semantic  orientations  of  Values  and  Features.  Special  agents  react  to  situations 
of  semantic  reduction  in  order  to  recover  missing  units.  A  few  agents  are  intended  to  realize  the  bottom-up  pro¬ 
cess  of  constructing  the  semantic  tree  by  finding  out  the  semantically  dominant  counterpart  for  any  SemWord 
node  and  creating  SemTree  relation  between  them.  All  the  semantic  agents  are  able  to  work  under  the  condition 
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“Wind"  “Stmthern"  “Souihwesicni"  ‘‘7.,12  m/sec" 


Fig.  3.  Topical  analysis 


that  Topic  related  to  the  SemWord  nodes  under  analysis  is  ’’worked_out”,  i.e.  the  topical  fragment  construc¬ 
tion  is  completed.  Consider  our  example  wind  south  south-west  7-12  m/s  and  its  resulting  semantic  structure 
presented  in  Fig.  4.The  indeterminate  Values  south,  south-west  ("WindDirection”  vs.  ’’Wind Variation”)  and 
7-12  m/s  (’’WindSpeed”  vs.  ’’WindGust”)  have  been  disambiguated.  The  basic  Features  (’’WindDirection”  and 
’’WindSpeed”)  have  been  recovered  due  to  the  DefaultFeatures  information  of  Element-Feature  relation  and 
the  corresponding  SemTree  relations  set  up.  Of  the  two  competing  Values  to  be  attached  to  the  recovered 
’’WindDirection”  Feature  node  the  first  one  has  been  chosen  by  a  special  condition  on  the  word  order.  Note 
that  semantic  trees  of  all  the  topical  fragments  of  the  text  will  be  further  connected  |;o  the  basic  Locative  and 
Temporal  units  immediately  or  via  their  local  circumstantial  units  (if  any). 


Feature 

“WindSpeed" 

NumericValuc 

“7,  I2in/sec" 


Fig.  4.  Semantic  analysis 


It  is  necessary  to  emphasize  that  all  agents  work  simultaneously.  While  lexical  agents  are  processing  the  input 
chain  and  creating  lexical  nodes,  topical  agents  are  assembling  them  in  coherent  text  fragments.  The  progress  of 
topical  analysis  is  being  provided  by  presemantic  agents  that  are  creating  the  required  conditions  in  the  lexical 
chain.  At  the  same  time  the  completely  analyzed  topical  fragments  are  subject  to  semantic  processing. 


6  Conclusion 

Several  questions  of  M-texts  processing  have  been  left  out  of  the  scope  of  this  paper.  Nevertheless,  we  hope  that 
we  have  managed  to  demonstrate  basic  principles  of  our  approach  including  semantics  orientation,  text  type 
consideration  ^d  processing  different  types  of  information  in  parallel.  The  use  of  ageht-based  technique  allows 
increasing  efficiency  of  data  processing  control  in  comparison  to  production  systems.  This  is  achieved  by  using 
the  associative  event-driven  mechanism  instead  of  an  expensive  pattern  matching  routine. 

Meteorological  telegrams,  with  their  text  specificity  and  lucidity  of  structure  of  underlying  problem  domain, 
appeared  to  be  a  good  testing  ground  for  experiments  and  development  of  the  agents  mechanism.  The  most 
interesting  perspective  seems  to  be  the  analysis  of  abbreviations  and  mistakes.  Disambiguation  of  deviating 
lexical  units  implies  local  multivariant  processing  that  can  be  efficiently  realized  within  the  framework  of  event- 
driven  approach. 
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Abstract.  We  propose  a  control  language  for  designing  single  constraint  solvers  as  well  as  their  collabo¬ 
rations.  Based  on  the  notions  of  constraint  filter,  separator,  and  sorter,  we  define  basic  strategy  operators 
that  allow  us  to  specify  single  solvers  and  their  collaboration  in  a  uniform  way.  We  exemplify  the  use  of 
this  language  by  specifying  some  techniques  for  solving  constraints  over  real  numbers. 


1  Introduction 

In  the  last  twenty  years,  much  work  has  been  done  on  solving  Constraint  Satisfaction  Problems  (CSPs)  [9]. 
The  existing  constraint  solvers  have  been  successfully  applied  for  solving  real-life  problems.  We  could  say  that 
constraint  solving  over  a  particular  domain  is  well-understood.  In  the  case  of  solvers  based  on  propagation,  either 
the  control  is  left  at  the  implementation  level,  or  the  strategy  is  fixed.  For  example,  to  be  completely  formal  when 
adding  strategies  to  Chaotic  Iteration,  we  must  prove  that  the  algorithm  and  the  strategy  really  compute  the 
same  fixed-point  as  Chaotic  Iteration  alone  [1].  Arc-consistency  algorithms,  originally  developed  just  for  binary 
constraints,  use  fixed  strategies  and  fixed  data  structures,  thus,  it  is  not  possible  to  change  the  strategy  [11,4]. 
Solvers  based  on  other  techniques,  such  as  Grobner  bases  and  the  simplex  method,  use  a  dedicated  strategy. 
Finally,  the  deductive  approach  used  in  COLETTE  allows  a  fine  control  of  the; computation,  the  strategy  being 
a  parameter,  but  there  is  no  solver  collaboration  and  some  features  are  hidden  in  the  implementation  language 
(such  as  AC  properties  and  term  manipulation)  [6]. 

Given  that  the  development  of  constraint  solvers  is,  in  general,  an  expensive  and  tedious  task,  the  interest 
for  reusing  existing  solvers  is  obvious  [18].  Even  more  important,  when  dealing  with  problems  that  cannot  be 
tackled  or  efficiently  solved  with  a  single  solver,  we  definitively  realise  the  interest  of  integrating  several  solvers, 
working,  in  general,  over  different  domains  [16, 3, 10, 17, 15].  This  is  called  Collaboration  of  Solvers  [12].  In  order 
to  make  solvers  collaborate,  the  need  for  powerful  strategy  languages  to  control  their  integration  has  been 
well  recognised  [13,14,2].  The  existing  approaches  consider  a  fixed  domain  (linear  constraints  [3],  non-linear 
constraints  over  real  numbers  [15, 10, 8]),  a  fixed  strategy,  and  a  fixed  scheme  of  collaboration  (sequential  [15, 8], 
asynchronous  [10]).  In  the  language  Bali,  the  collaboration  is  specified  using  control  primitives.  The  constraint 
system  is  a  parameter,  but  the  control  capabilities  for  specifying  strategies  are  not  fine  enough  [14]. 

In  this  paper,  we  propose  a  control  language  for  specifying  single  constraint  solvers  and  their  collaborations. 
Based  on  [5],  a  solver  is  viewed  as  a  strategy  that  specifies  the  order  of  application  of  elementary  operations 
expressed  by  transformation  rules.  In  this  framework,  different  domains  mainly  mean  the  definition  of  different 
transformation  rules,  and  different  heuristics  mean  different  strategies.  Extending  this  idea,  we  consider  the 
collaboration  of  solvers  as  a  strategy  that  specifies  the  order  of  application  of  single  or  component  solvers. 

Our  main  motivation  is  to  provide  a  general  framework  for  defining  single  constraint  solvers  in  a  formalism 
that  allows  to  specify  high  level  operations  on  constraints  as  well  as  syntactical  transformations  normally 
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hidden  in  the  current  implementations  of  constraint  solvers.  Our  interest  is  to  define  this  framework  in  a  wa}'- 
that  allows  its  natural  extension  for  specifying  the  collaboration  of  solvers,  since  the  design  of  constraint  solvers 
and  the  design  of  collaboration  of  solvers  require  similar  methods  (strategies  are  often  the  same:  don’t-care, 
fixed  point,  iteration,  parallel,  concurrent,  ...)  In  other  words,  we  propose  a  language  for  writing  single  solvers 
and  collaboration  at  the  same  level,  making  explicit  things  that  are  generally  hidden  in  the  implementations; 
strategies,  properties  of  the  operators  (AC,...) 

We  have  already  used  our  control  language  to  design  several  solvers  with  several  strategies,  among  them,  a 
simplex  algorithm,  Grobner  bases  computation,  and  a  solver  for  constraints  over  finite  domains.  However,  for 
lack  of  space,  we  only  present  one  example  in  this  paper:  a  solver  for  constraints  over  real  numbers.  For  the 
same  reason,  we  do  not  include  in  this  paper  two  strategy  operators  of  our  language,  mainly  designed  to  make 
solvers  collaborate  [7]. 

This  paper  is  organised  as  follows:  Section  2  presents  some  standard  definitions.  In  Section  3,  we  introduce 
the  basic  components  of  our  control  language.  The  language  itself  is  presented  in  Section  4  and  illustrated  in 
Section  5  with  the  design  of  solvers  for  constraints  over  real  numbers.  In  section  6,  we  conclude  the  paper. 

2  Definitions 

Definition  1.  A  constraint  system  is  a  4-tuple  {S,T>,V,C)  where: 

-  S  is  a  first-order  signature  given  by  a  set  of  function  symbols  and  a  set  of  predicate  symbols  Vs, 

-  T>  is  a  IJ -structure  (its  domain  is  denoted  by  |D|j, 

-  V  is  an  infinite  denumerable  set  of  variables, 

-  C  is  a  set  of  constraints:  a  non-empty  set  of  [S ,V)-atomic  formulae,  called  atomic  constraints,  closed  under 
conjunction  and  disjunction.  The  unsatisfiable  constraint  is  denoted  by  1  and  the  true  constraint  is  denoted 
by  T.  The  set  of  atomic  constraints  is  denoted  CAt- 

An  assignment  is  a  mapping  a  :  V  \V\.  The  set  of  all  assignments  is  denoted  by  ASS^.  An  assignment 
a  extends  uniquely  to  an  homomorphism  a  :  T(i;,V)  ->  |D|.  The  set  of  solutions  of  a  constraint  c  C  £  is  the 
set  Solv{c)  of  assignments  a  €  ASS^  such  that  a(c)  holds.  A  constraint  c  is  valid  in  T>  (denoted  by  V  c) 
if  Solvic)  =  ASS^.  We  denote  by  Var(c)  the  set  of  variables  from  V  occuring  in  the  constraint  c.  Finally,  we 
introduce  the  notion  of  solver. 

Definition  2.  A  solver  for  a  constraint  system  {S,V,  V,  C)  is  a  computable  function  S  ■.  C C  such  that 

1.  yC  £  C,  SoIt:){S{C))  C  Sol-DiC)  (correctness  property) 

VC  £  C,  SoIt){C)  C  SoIt>{S{C))  (completeness  property) 

A  constraint  C  is  imsolved  form  with  respect  to  S  if  5(C)  =::  C.  Given  a  constraint  system  (S,V,V,C)  and 
a  solver  5  over  {E,  V,  V,  C),  such  that  C  C  C,  we  extend  5  to  [S,  V,  V,  C)  in  the  following  way:  ^  C  £C\C', 


3  Filters  and  Sorters 

We  now  define  the  basic  components  of  our  strategy  language:  filters  to  select  specific  parts  of  a  constraint,  and 
sorters  to  classify  the  elements  of  a  list  w.r.t.  a  given  ordering.  We  introduce  the  notion  of  filter  for  two  main 
reasons.  A  solver  can,  in  general,  be  tried  on  several  parts  of  a  constraint  [5].  Second,  when  dealing  with  solver 
collaborations,  in  general,  a  single  solver  is  not  able  to  treat  the  complete  constraint  [13].  In  both  cases,  we  want 
to  identify  the  sub-parts  of  the  constraint  the  solver  is  actually  able  to  handle.  Once  we  have  identified  these 
parts,  we  generally  want  to  choose  some  of  them  based  on  a  given  criterion^  Thus,  we  introduce  the  notion  of 
sorter  that  is  associated  to  a  notion  of  strategy. 

We  consider  that  the  equality  =  is  purely  syntactical.  Thus,  we  say  that  C  is  a  syntactical  form  of  C,  denoted 
hyC'FsC,]iC'-C  modulo  the  associativity  and  commutativity  of  A  and  V,  and  the  distributivity  of  A  on  V  and 
of  V  on  A.  In  other  words,  a  filter  returns  an  equivalent  constraint  when  we  block  the  associative,  commutative, 
and  distributive  properties  of  the  operators.  We  denote  by  ST{C)  the  finite  set  of  all  the  syntactical  forms  of 
a  constraint  C:  ST{C)  =  {C"|  C  ss  C}^.  We  say  that  C"  G  £  is  a  sub-constraint  of  C,  denoted  by  C[c’])  if: 

^  Minimum  Domain  criterion,  for  example,  when  dealing  with  finite  domains. 

The  ACD  theory  defines  a  finite  set  of  quotient  classes  that  we  can  effectively  filter. 
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-  3Ci,C2  €  C,  Wi,W2  €  {a,  v},  C  —  CiWiC'ui2C2 

-  or  3Ci  eC,uje  {A,  V},  C  =  CiojC 

-  or  aCi  e  £,  w  G  {A,  V},  C  =  C'loCi 
-orC^C 

A  couple  {C",  C)  such  that  C"  is  a  sub-constraint  of  C  and  C7'  w  C7  is  called  an  applicant  of  C.  We  denote 
by  CA  the  set  of  all  the  lists  of  applicants,  and  by  CC  the  set  of  all  the  lists  of  constraints.  Generally,  we  will  use 
LA  to  denote  a  list  of  applicants,  and  LC  to  denote  a  list  of  constraints.  We  denote  hy  V{C  x  C)  the  power-set 
of  all  the  sets  of  couples  of  constraints.  Finally,  v4tom(C7)  denotes  the  set  of  atomic  constraints  that  occur  in  C\ 
{c|c  €  Cai  and 

Definitions.  Let  {E,'D,V,C)  be  a  constraint  system.  A  filter  (j)  on  {S,V,V,£)  is  a  computable  function 
<p  :  C  V{£  X  £)  such  that: 

yCe£,  4>iC)  =  {(Cf,C%...,(Cr,C^)},  where 

-  Vi  €  [l,n],  C  Pi  (C'’  is  a  syntactical  form  of  C), 

-  Vi  G  [IjU.],  ' 

The  elements  of  <^((7)  are  called  candidates.  Given  the  filters  ^  and  (fi  on  (S,T>,V,£),  we  say  that: 

-  ^  is  selective  if  VC  G  £,  (f>{C)  =  {(C/i,  Ci), . . . ,  (C/„,  C„)}  such  that 
'di,je[l..n]x[l..n],Atom(Cfi)nAtom{Cfj)  =  ^. 

-  <l>  is  stable  if  VC  G  £,  =  {(C/i, C'),  •  •  • ,  (C/„, C')} 

-  ^  and  <f>‘  are  disjoint  if  VC  G  £,  ^(C)  =  {(C/i,  Ci), . . . ,  (C/n,  C„)},  and  - 
<^'(<7)  =  {(C/{,  C{), . . . ,  (C/;„,  c;„)},  such  that  V(i,  j)  G  [l..n]  X  [l..m], 

Atom(Cfi)  n  Atom{Cfj)  =  0. 

Example  1.  Consider  the  constraint  system  (27,  P,  V,  £)  s.t.  the  predicate  G  is  in  27,  and  that  £  contains  some 
domain  constraints,  i.e.  X  G  Dx,  where  Dx  (the  domain  of  X)  specifies  the  values  the  variable  X  can  taJce. 
We  now  define  a  filter  for  these  domain  constraints: 

VC  G  A  <^Com(C)  =  {(c,  C)|C[e]  and  3X  G  V,  c  =  (X  G  Px)} 

4>Dom  is  stable  and  selective.  We  denote  by  Cjdqto  the  elements  of  £At  resulting  of  the  application  of  this  filter. 
We  will  re-use  this  notation  in  other  examples. 

Example  2.  We  now  consider  patterns  of  constraints.  The  utility  of  this  filter  will  be  clarified  in  Section  5. 
We  want  to  filter  sub-constraints  that  are  the  conjunction  of  a  domain  constraint,  an  atomic  constraint,  arid  a 
conjunction  of  domain  constraints,  i.e.  ,  an  atomic  constraint,  and  all  the  domain  constraints  of  the  variables 
occuring  in  it. 

VC  G  £,  (t>D/\cADs{C)  C  £^  and  (j>DAcADs{C)  is  defined  as  follows: 

1.  Patterns: 

{C" ,C')  G  4>dacaDs{C)  C"  —  {X  G  Dx)  A  c  AyeVa7’(c)\{x}  ^  ^ 

A  c  G  £At  \  £d  om  ^  C  G  SF{C) 

ACjf;,,]  A  X  G  Var-(c) 

2.  Context-free: 

((O',  Cl)  G  j>DAcADs(C)  A  (C',C2)  G  <l>DAcADs(C))  Cl  =  C2 

3.  Commutative-free: 

(X  G  Dx  A  C  A  C",Ci)  G  <j>DAcADs(C)  \  .  fill  ^ 

A  (X  G  A  c  A  C^',  C2)  G  J  '  ~ 

Items  2  and  3  are  not  mandatory,  but  they  reduce  the  number  of  applicants.  This  definition  does  not  provide 

uniqueness  to  the  filter.  Depending  on  our  needs,  we  can  consider  (1)  adding  requirements  to  define  one  set 

of  applicants  per  constraint,  (2)  removing  Item  2  and  3,  or  (3)  selecting  one  of  the  set  corresponding  to  the 
definition. 

Definition  4.  A  sorter  Sorter,  w.r.t.  a  partial  ordering  ■<,  for  a  constraint  system  (27,P,  V,  £)  is  a  computable 
function  Sorter  xV(£x  £)  -^  £A  such  that\/{(Cfi,,Ci,^),...,(Cfi^,Ci^)}  e'P(£x  £): 

1.  Sorter(^,{{Cfi„Ci,),...,{Cfi„,CiJ})  =  [(Cfi,Ci),...,(Cfn,Cn)] 
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B.  V/c  €  [1, n], 3j  E  [1, n],  Cfi-  =  Cfk  and  Q,  =  Ck 
S.yjE[l..n-l],Cfj^Cfj+i 

Remark  1.  We  consider  that  a  sorter  is  determinist  i.e.,  if  L  is  a  set  of  applicants,  each  application  of  a  sorter 
on  L  will  alwa5^s  return  the  same  list  of  applicants. 

Example  3  (MaxDom  and  MinDom  sorters).  :<Dom  is  an  ordering  based  on  the  width  of  the  domain  involved 
in  the  domain  constraints.  For  atomic  domain  constraints,  MaxDom  and  MinDom  are  straight-forward,  but  we 
may  need  to  consider  these  orderings  for  more  complex  constraints  (e.g.,  patterns  of  constraints  issued  from 
filters).  MaxDom  and  MinDom  use  the  width  of  domains  of  variables.  Let  X  E  Dx  be  a  domain  constraint,  we 
consider  the  generic  function  w  which  gives  the  width  of  a  domain.  We  define  the  function  width  as  follows: 

-  if  c  £  jCoom  and  c  —  X  E  Dx,  then  W(c)  —  u>{Dx), 

-  if  c  €  Cm  \  Drtom,  then  W{c)  —  -1 

-  if  (7  =  c  A  C"  or  (7  =  c  V  C"  and  c  €  Cau  then  W{C)  =  W{c). 

':^Dom  is  now  defined  by:  VC,  (7'  E  C,  C  -^Dom  C  if  W{C)  <  W{C').  The  sorter  MinDom  (resp.  MaxDom)  is 
defined  using  the  :<Dom  ordering  (resp.  >:Dom,  the  reverse  ordering  of 


4  The  Strategy  Language 

Given  a  solver  S,  a  filter  ^  and  a  partial  order  we  now  define  several  application  mechanisms  for  appljdng 
solvers  to  constraints.  We  assume  that  a  solver  is  applied  only  once  on  a  given  set  of  constraints.  In  the  following, 
we  consider  given  a  constraint  system  CS  =  (27,  D,  V,  C).  Most  of  the  application  mechanisms  are  based  on  the 
same  technique  when  applied  to  a  constraint  (7; 

1.  A  set  SC  of  candidates  is  built  using  the  filter  (j)  on  C. 

2.  The  set  SC  is  sorted  using  ■<:  we  obtain  LC  =  [{Cfi,Ci), ,  ((7/„,  Cn)],  a  sorted  list  of  candidates,  where 
((7/i, Cl)  is  the  “best”  constraint  w.r.t. 

3.  The  solver  S  is  applied  on  one/several  element  of  LC. 

4.  Sub-constraints  modified  by  S  are  replaced  in  their  corresponding  syntactical  form  of  C. 

4.1  Basic  Solver  Compositions 

The  following  operators  are  standard  and  analagous  to  function  compositions.  They  are  used  to  design  solvers 
with  “basic”  functions,  or  create  solver  collaborations  with  “complex”  solvers.  Let  R  and  5  be  two  solvers  on 
(27,1),  V,£).  Then,  VC  ££  we  define: 

-  S^{C)  =  C  {Identity) 

-  S-,R{C)  =  R{S{C))  {solver  concatenation) 

-  iS"(C)  =  S”'~^',  S{C)  if  n  >  0  {solver  iteration) 

-  S*{C)  =  S^{C)  such  that  S^'^^{C)  =  S’^{C)  {solver  fixed-point) 

-  (5, ii)(C)  =  S{C)  or  R{C)  {solver  don’t-care) 

Property  1.  S-,R,  S’^,  S*,  and  {S,R)  are  solvers. 

4.2  Filtered  and  Random  Application  of  a  Solver 

We  first  define  two  operators  to  apply  a  solver  on  specific  components  of  a  constraint.  The  first  one  takes  the 
component  randomly  whereas  the  second  one  selects  it  with  respect  to  a  given  criterion. 

Don’t  Care  Application  of  a  Solver  Given  a  solver  S,  a  filter  (f),  and  a  constraint  C,  dc(5,  (ft)  restricts  the 
use  of  the  solver  S  to  one  sub-constraint,  chosen  randomly,  of  a  syntactical  form  of  C  (obtained  using  the  filter 
4>): 

VC  £  £,dc(5,(/i)(C)  =  C',  where 

-  [iCfuC,),...,{CU,Cn)]  =  (l>{C) 

-  if  there  exists  i  £  [l..n]  such  that  S{Cfi)  ^  Cfi  ,  then  C  =  Ci{Cfi  ^  S{Cfi)],  otherwise  C  =  C. 
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Best  Application  of  a  Solver  Given  a  solver  5,  a  partial  order  on  £,  a  filter  and  a  constraint  C, 
restricts  the  use  of  the  solver  S  to  the  best  (w.r.t.  the  partial  order  <)  sub-constraint  of  a 
syntactical  form  of  C  (obtained  using  the  filter  (f>)  that  S  is  able  to  modify: 

VC  €  >C,best(5,  :::<,(^)(C')  =  C",  where 

-[{Ch,Ci),...,{Cfn,Cn)]^Sarter{^,ct>{C)) 

-  if  there  exists  i  €  [l..n],  such  that  S{Cfi)  7^  Cfi,  and  Vj  6  [l..n]  {S{Cfj)  ^  Cfj  ^  i  <  j)  then  C  = 
Ci{Cfi  !-)■  S'(C'/i)}, otherwise  C  =  C. 


4.3  Concurrent  and  Parallel  Applications  of  Solvers 

We  now  define  two  operators  to  apply  several  solvers  on  a  constraint.  The  first  one  chooses  only  one  result 
depending  on  a  given  criteria.  The  second  one  composes  the  final  result  based  on  each  application. 


Concuirrent  Application  of  a  Solver  The  operator  pcc  provides  a  non-deterministic  choice  upon  which  we 
act  by  introducing  different  methods:  we  do  not  care  about  which  solver  actually  solved  the  constraint,  but 
we  want  the  result  to  verify  some  property.  A  constraint  property  p  on  a  constraint  system  {E,V,V,C)  is  a 
function  from  constraints  to  Booleans  (i.e.,  p  :  Boolean).  Given  a  list  of  solvers  [5i,...,5„],  a  list  of 

orders  on  constraints  . . . ,  a  list  of  filters  [</>!,...,  and  a  property  p,  pcc(p,  [^i, . . . ,  5^], 

],  [^1, . . . ,  (j)n])  applies  once  one  of  the  solvers  Si  on  a  constraint  that  verifies  the  property  p: 

VGe  i:,pcc(p,[5i,...,5„],[::<i,...,::^„],[^i,...,</>„])(C')  =C",  where 

-  for  ali  i  e  [l..n]  . . . ,  5orter(:^i,  ^i(C')) 

-  if  there  exists  {i,j)  e  [l..n]  x  such  that  piSi{Cfij)),  and  Si{Cfij)  7^  Cfijthen  C  =  Cij{Cfij  i-> 

Si{Cfij)},  otherwise,  C  —  C. 


Parallel  Best  Applications  of  Solvers  Given  a  list  of  solvers  [5i,...,5n],  a  list  of  orders  on  constraints 
[di)  •  •  •  1  a-iid  a  list  of  stable  filters  that  are  pairwise  disjoint,  bp([5i, . . . ,  5„],  [;^i, . . . , 

],  {d>i , . . . ,  (j>n])  applies  n  solvers  Si,..  .,Sn  on  n  sub-parts  of  one  syntactical  form  of  the  constraint: 

VG  e  C,  bp([5i,...,S„],[::^i,.. [0i,-.-,<;6n])(G)  =  G',  where 

-  for  all  i  G  [l..n]  [{C  fi,i,C"), ...  ,{Cfi,m,,C")]  ^  Sorter  (-^1,^0)) 

-  for  all  i  £  [l..n],  if  there  exists  j  £  [l-mj],  such  that  Si{Cfi.)  7^  Cfi.,&nA  for  all  k  <  j,  Si{Cfi,,)  =  Cfi^, 
then  (Tj  =  {G/i,i,.  (->•  5,(G/j,jJ},  else  CTi  =  0. 

-  G'  =  C"a  where  a  =  Uie[i..n] 

4.4  Properties  of  the  component  functions 

In  spite  of  its  simplicity,  the  following  property  is  essential:  it  allows  one  to  manipulate  component  functions 
and  solvers  at  the  same  level,  and  thus  to  create  solver  collaboration  with  the  same  strategy  language. 

Property  2.  best,  dc,  pcc,  and  bp  are  solvers. 

5  Example:  Solvers  for  Constraints  Over  Real  Numbers 

We  now  design  solvers  for  non-linear  real  constraints  using  real  interval  arithmetics.  In  the  following,  a  CSP  P 
is  any  conjunction  of  formulae  of  the  form  f\^.^x{xi  £  A  G  where  a  domain  constraint  Xi  €  D^i  is  created 
for  each  variable  Xi  occuring  in  the  set  of  constraints  G,  Dxi  being  an  interval  of  real  numbers.  Constraints  are 
equalities  of  non-linear  polynomials. 

MaxDom  partial  ordering  We  instantiate  the  MaxDom  sorter  of  Example  3:  for  all  interval  I  -  fo,  6], 
u}{I)  =  b  —  a. 

The  split  solver  transforms  a  domain  constraint  into  a  disjunction  of  two  domain  constraints  if  the  width  of  the 
domain  is  greater  than  or  equal  to  a  “minimal”  width  e:  split  \  L C.  For  all  c  =  X  G  Dx  from  C, 
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~  if  c  G  £-Dom  such  that  width(^c)  >  e,  then  split{c)  —  X  E  D'x  V  €  D'y  where  Dx  —  D'v  U  D'l-  ^ 

-  otherwise,  split{c)  =  c.  ^  x  . 

A  domain  reduction  function  Consider  the  function  bjc  which  given  a  non-linear  constraint  c  £  jC-At  \£-Dom> 
the  domain  Dx  of  a  variable  X  £  Var{c),  and  the  domains  of  the  other  variables  of  Var(c),  returns  a  smaller 
domain  for  X  s.t.  c  is  box-consistent  [19]  w.r.t.  X  (i.e.,  Dx  cannot  be  further  reduced  without  loosing  any 
solution).  We  can  now  define  the  solver  drf  :  C C.  For  all  C  £  £,  we  compute  drf(C)  depending  on  the 
syntactical  form  of  C; 

-  if  C  =  X  £  Dx  Ac  A  AYeVar{c)\{x}  y  ^  Dy  where  c  £  \  Coom,  then, 

drf{C)  —  X  £  D'x  Ac  A  Ay6Var(c)\{x}  ^  ^ 
where  D'^  =  b.c{c,  Dx,  {Dy\Y  £  Var(c)  \  {A}}), 

-  otherwise,  drf{C)  =  C. 

Solvers  We  now  consider  the  solver  box  defined  as  follows: 

box  =  hest{drf,tDom,<l)DAcADs)  ; 

When  applied  to  a  CSP  C ,  box  executes  one  step  of  reduction:  one  atomic  constraint  of  C  becomes  box-consistent 
with  respect  to  the  largest  variable  of  the  CSP.  Let  us  now  consider  the  following  solver: 

Box  =  box* 

Box  is  the  least  fixed-point  of  box.  When  applied  to  a  CSP  Box  returns  an  equivalent  CSP  that  is  box- 
consistent.  The  strategy  of  this  solver  is  to  always  reduce  the  variable  with  the  largest  domain  i.e.,  a  well-known 
and  commonly  used  strategy  for  interval  arithmetics. 

Solving  CSPs  is  generally  the  iteration  of  two  mechanisms:  consistency  (described  above)  and  splitting.  We 
now  describe  the  splitting  mechanism  which  enables  to  extract  the  isolated  solutions: 

Split  =  best(split,  yoom,  <^d) 

Applied  to  a  CSP  C,  Split  creates  a  disjunction  of  two  sub-CSPs.  We  can  now  define  the  solver  for  solving 
CSPs  over  non-linear  constraints: 

SpullLookAhead  —  {BoX\  Split)* 

This  strategy  corresponds  to  a  full  lookahead  approach:  each  time  a  domain  is  split,  the  consistency  of  the  CSP 
is  recomputed.  At  a  lower  level,  the  strategy  for  applying  basic  solvers  is  a  Max-Dom.  The  solving  process  is 
neither  depth-first  nor  breadth-first  but  Max-Dom  first,  i.e.,  we  make  one  reduction  step  on  one  branch,  and 
then,  we  eventually  choose  to  explore  another  branch. 


6  Conclusions 

We  have  presented  the  definition  of  a  control  language  for  solving  CSPs.  A  key  point  in  this  work  is  the 
introduction  of  the  concepts  of  constraint  filter,  separator,  and  sorter.  These  operators  allow  us  to  show  in  the 
strategy  language  the  S3mtactical  transformations  generally  hidden  in  the  current  solvers.  Then,  using  these 
operators,  we  have  defined  a  set  of  constructors  that  allow  to  define  single  solvers  as  well  as  the  collaboration 
of  solvers.  We  have  exemplified  the  use  of  this  language  by  the  simulation  of  well-known  techniques  for  solving 
constraints  over  real  numbers.  To  show  the  broad  scope  of  potential  applications  of  our  control  language, 
we  have  already  designed  several  solvers  that  are  considered  of  different  nature  (such  as  Simplex  algorithm,’ 
propagation  based  solvers,  and  Grobner  bases  computation).  We  are  currently  working  on  the  implementation 
of  this  language  in  order  to  evaluate  the  real  applicability  of  this  framework. 
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Abstract.  Interval  constraint-based  solvers  are  valuable  tools  to  scientists  and  engineers  since  they  ensure 
many  useful  properties  such  as  completeness  of  the  result.  However,  their  lack  of  soundness  is  sometimes 
a  major  flaw.  This  paper  presents  an  algorithm  ensuring  soundness  by  computing  inner  approximations 
of  real  relations  using  only  “traditional”  numerical  methods.  A  slight  modification  of  the  algorithm  per¬ 
mits  handling  constraint  systems  with  one  universally  quantified  variable.  An  application  to  declarative 
modelling  of  camera  movements  is  also  described. 


1  Introduction 

Expressiveness,  efficiency,  and  reliability  of  interval  constraint-based  tools  [16,  2,  4]  make  them  a  solution  of 
choice  for  solving  non-linear  systems  of  equations  such  as  the  ones  arising  in  robotics  [13],  chemistry  [11],  or 
electronics  [14].  Relying  on  interval  arithmetic  [12,  1],  these  tools  ensure  completeness  (all  solutions  present 
in  the  input  are  retained),  and  permit  bracketing  solutions  with  an  “arbitrary”  accuracy.  On  the  other  hand, 
soundness  is  not  guaranteed,  while  it  is  sometimes  a  strong  requirement.  For  example,  consider  a  civil  engineering 
problem  [15]  such  as  floor  design  where  retaining  non-solution  points  may  lead  to  a  physically  unrealizable 
structure. 

This  paper  presents  an  algorithm  whose  output  is  a  set  of  sound  boxes  of  variable  domains  for  some  con¬ 
straint  system.  Soundness  is  achieved  by  computing  inner  approximations  of  real  relations  using  box  consis¬ 
tency  [3]— -a  well-known,  efficient,  local  consistency  [10] — on  the  negation  of  the  involved  constraints.  Next,  a 
slight  modification  of  the  algorithm  is  described,  which  permits  solving  constraint  systems  where  one  variable  is 
universally  quantified.  Its  application  to  temporal  constraints  describing  camera  movements  {virtual  cameraman 
problem  [9])  is  then  presented  along  with  some  preliminary  results. 

The  organization  of  the  paper  is  as  follows:  Section  2  introduces  the  basics  related  to  interval  constraint 
solving;  Section  3  presents  an  extension  of  the  theoretical  framework  given  in  Section  2  to  support  the  notion 
of  inner  approximation,  along  with  the  corresponding  new  algorithms;  Section  4  describes  modifications  of 
the  algorithms  of  Section  3  permitting  to  consider  constraint  systems  with  one  universally  quantified  variable; 
Section  5  discusses  the  use  of  the  algorithms  for  the  “virtual  cameraman  problem”;  finally.  Section  6  synthesizes 
the  contribution  of  the  paper,  and  points  out  future  directions  for  improvement  of  the  methods  described 
hereinafter. 


2  Interval  Constraint  Solving 

Finite  representation  of  numbers  by  ramputers  hinders  exact  solving  of  real  constraints.  Underlying  real  relations 
must  be  approximated  by  considering  one  of  their  computer-representable  superset  or  subset.  This  section 
presents  the  basics  related  to  the  approximation  of  real  relations  the  conservative  way.  Approximation  by  a 
subset  is  deferred  until  the  next  section.  The  shift  from  reals  to  floating-point  intervals  is  first  described;  the 
notion  of  outer  approximation  of  a  real  set  based  on  intervals  is  then  presented. 

2.1  Preliminary  notions 

Let  1  be  the  set  of  reals  and  F  c  1  a  finite  countable  subset  of  reals  corresponding  to  floating-point  numbers 
m  a  given  format  [8].  Symbol  oo  is  introduced  to  represent  infinity,  that  is:  Vg  G  F:  —  oo  <  g  <  -fcx)  and 
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M  C  (-cx)  ..  +oo).  Let  =  FU  {-oo,+oo}.  Hereafter,  r  and  s  (resp.  g  and  h),  possibly  subscripted,  are 
assumed  to  be  elements  of  E  (resp.  F°°). 

Let  C  —  {(,  [}  (resp.  U  =  {),]})  be  the  set  of  left  (resp.  right)  brackets.  Let  B  =  jCUU  he  the  set  of  brackets 
totally  ordered  by  the  ordering  [6]:  )  ^ 

The  set  of  floating-point  bounds  F®  is  defined  from  B  and  F  as  follov/s: 


IP  =  IP  U  IP 


where 


rr  =:(Fxz:u{(-oo,(),(+oo,(>}) 
Ir  =  (Fxi/U{(-oo,)),(+oo,))}) 


Real  bounds  set  E*  is  defined  likewise.  Floating-point  bounds  are  totally  ordered  by  the  ordering  <:  V/9i  = 
( gi  o<i ),  /?2  =  (  h,  a2  )  e  IP  :  /3i  <1/32  (g  <  h)  V  (g  =  h  A  ai  -<  02) •  A  similar  ordering  may  be  defined  over 
E^ 

Rounding  operations  mapping  real  bounds  to  float  bounds  are  defined  as  follows: 


Bound  downward  rounding 


Bound  upward  rounding 


y 


>]p 

max{7  £  IP 


y:  IP 


IP 


fl  I — >■  min{7  6  IP  |  7  P  /3} 


Bounds  are  used  to  construct  intervals  as  follows:  lo  =  IP  x  IP  is  the  set  of  closed/open  floating-point 
intervals  (henceforth  referred  as  intervals),  with  the  following  notations  used  as  shorthands  (((  g,  [ ),  (  h,] ))  = 
[g  ••  h]  =  ^  ®  I  g  ^  I"  ^  li})  etc.).  For  the  sake  of  simplicity,  the  empty  set  0  is  uniquely  represented  in  Ho  by 

the  interval  (+00  ..  —00). 

In  the  rest  of  the  paper,  a  Cartesian  product  of  n  intervals  B  =  /i  x  •  •  •  x  /„  is  called  a  box.  A  non-empty 
interval  1  =  (^1,^2)  with  ,81  G  F^  and  ^2  G  IP  is  said  canonical  whenever  /?2|u  ^  (/3i|^)+,  where  is  the 
numerical  part  of  bound  fl,  and  g+  is  the  smallest  float  greater  than  g.  A  n-ary  box  B  is  canonical  whenever 
the  intervals  /i, . . . ,  are  canonical.  Given  a  variable  v,  an  interval  I,  and  boxes  B  and  D,  let  DomB(u)  G  lo 
be  the  domain  of  v  in  box  B,  and  the  box  obtained  by  replacing  v  domain  in  box  B  by  its  domain  in 

box  D.  The  power  set  of  a  set  S  is  written  V(S). 


2.2  Approximating  a  relation  by  a  box 

A  constraint  is  an  atomic  formula  involving  variables  of  Vk  =  {xi,X2, ...}.  Given  a  constraint  c{xi,. . . ,  »„), 
denotes  the  underlying  real  relation.  For  the  sake  of  readability,  relation  p^,  for  some  constraint  a  is  written  pi 
whenever  that  notation  is  non-ambiguous.  Let  c  be  -<c,  that  is:  Pc  =  E"  \  pc- 

A  real  relation  p  may  be  approximated  conservatively  by  the  smallest  box  (w.r.t.  set  inclusion)  Outer,, (p) 
containing  it. 

Discarding  values  of  the  variable  domains  for  which  a  constraint  c  does  not  hold  is  done  by  contracting 
operators,  whose  main  properties  are  contractance,  completeness,  and  monotonicity. 

The  outer-approximation  operator  OClc  is  a  contracting  operator  for  c  that  tightens  variable  domains  using 
the  Outefo  approximation: 

Definition  1  (Outer-approximation  operator).  Let  c  be  a  n-ary  constraint,  p^  its  underlying  relation, 
and  B  a  box.  A  outer-approximation  operator  of  c  is  a  function  OClc:  I”  — ^  I”  defined  by:  OClJB)  = 
Outero(Bnpc) 

Proposition  1  (Completeness  of  OCl).  Given  a  constraint  c,  the  following  relation  holds  for, every  box 
B :  (B  n  Pc)  COClaiB) 

The  implementation  of  outer-approximation  operators  is  easily  done  only  for  a  limited  class  of  constraints 
(primitives).  The  other  constraints  are  solved  by  decomposing  them  into  conjunctions  of  primitives.  In  order  to 
overcome  the  loss  of  domain  tightening  due  to  the  introduction  of  new  variables  by  the  decomposition  process, 
Benhamou  et  al.  [3]  defined  a  new  kind  of  operator  (outer-box  approximation  operator  OCb)  which  considers 
constraints  globally.  The  following  relation  between  OCb  and  OCl  does  hold: 

Proposition  2  (Completeness  of  OCb).  Given  a  constraint  c,  and  a  box  B:  (B  11  pc)  C  Outers (B  Cl  pc)  C 
OCbc(B). 

Operators  OCl  and  OCb  narrow  the  domains  of  variables  occurring  in  one  constraint.  Solving  constraint 
systems  is  done  by  an  algorithm  (OC2)  which  computes  the  greatest  common  fixed-point  included  in  the  initial 
domains  of  all  the  contracting  operators  associated  to  each  constraint  (see  details  in  [5]). 
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3  Inner  Approximations 

In  order  to  compute  only  solution  sets,  the  outer-approximation  of  a  relation  p  c  1™  is  replaced  by  the  inner 
approximation  of  p  which  is  the  subset  of  all  the  elements  r  6  M"  for  which  the  statement  r  e  p  may  be  checked 
using  only  floating-point  numbers. 

Definition  2  (Inner  approximation  of  a  relation).  Given  a  n-ary  relation  p,  the  inner  approximation  of 
p  is  defined  by: 

Innero(p)  =  {r  €  M”  |  Outero({r})  C  p} 

Proposition  3  (Properties  of  the  Inner  approximation).  The  Inner  approximation  is  monotone,  idempo- 
tent,  and  distributive  w.r.t.  the  union  and  intersection  of  subsets  o/E”. 

The  narrowing  of  variable  domains  occurring  in  a  constraint  is  done  in  the  same  way  as  in  the  outer- 
approximation  case:  an  inner-approximation  operator  associated  to  each  constraint  discards  from  the  initial  box 
all  the  inconsistent  values.  The  result  is  a  set  of  boxes. 

Definition  3  (Inner-approximation  operator).  Let  c  be  a  n-ary  constraint,  and-B  a  box.  A  inner-appro¬ 
ximation  operator  of  c  is  a  function  IClg:  I"  P(I”)  defined  by: 

IClc(D)  C  lnnero(D  n  pc) 

Proposition  4  (Soundness  of  ICl).  Given  a  constraint  c  and  a  box  B,  a  inner-approximation  operator  IClc 
for  c  is  such  that  IClc(J5)  C  (JB  n  pc) 

Proposition  4  is  an  immediate  consequence  of  Inner  and  Outer  definitions. 

Inner-approximation  operators  with  stronger  properties  may  be  defined,  provided  some  assumptions— namely 
the  ability  to  compute  the  “Outer”  for  constraint  expressions—,  are  fulfilled.  These  operators  are  optimal  in  the 
sense  defined  below. 

Definition  4  (Optimal  inner-approximation  operator) .  ief  cbea  n-ary  constraint,  B  a  box,  and  IClc  an 
inner- approximation  operator  for  c.  IClc  is  said  optimal  if  and  only  if  lClc(J3)  =  lnnero(J3  D  pc) 

Devising  an  inner-approximation  operator  for  a  constraint  is  not  as  easy  as  devising  an  outer-approximation 
operator  since  interval  techniques  only  permit  to  enforce  some  partial  consistencies,  that  is,  values  which  are 
discarded  are  guaranteed  to  be  non-solutions  while  no  information  is  known  about  those  which  are  kept.  Al¬ 
gorithm  1  (ICAlc)  implements  an  optimal  inner-approximation  operator  for  every  n-ary  constraint  c  by  using 
OClc.  Since  values  discarded  by  this  operator  are  guaranteed  to  be  non-solution  of  c — by  completeness  of  OCl— , 
they  are  guaranteed  solutions  for  c. 


Algorithm  1.  ICAlo  -  Inner  contracting  algorithm  for  a  constraint  c 


1  ICAlc(m:  B  g  nj;  out :  W  g  P(I”)) 

2  begin 

3  D  <r-  OClc-(J5) 

4  u  <-  B\n 

6  if  {D  /  0  and  -iCanonical(jD))  then 

6  (Di, D2)  e- PlainSplit(-D) 

7  a  i-U\J  ICAlc(Di)  U  ICA1c(I>2) 

8  endif 

fl  return  (U) 

10  end 


The  PlainSpfit  function  used  in  the  algorithm  splits  in  two  intervals  one  of  the  non-canonical  domains  of  D.  In 
non-canonieal  domain  js  chosen  in  turn  in  a  round-robin  fashion  at  each  call  of  PlainSpKt. 


a  typical  implementation,  each 


Handling  constraint  systems  using  inner-approximation  operators  is  done  by  Algorithm  ICA2  (see  Algo¬ 
rithm  2):  each  constraint  of  the  system  is  considered  in  turn  together  with  the  sets  of  elements  verifying  all  the 
previously  considered  constraints  so  far.  The  main  difference  between  OC2  and  ICA2  lies  in  that  each  constraint 
needs  only  be  considered  once,  since  after  having  been  considered  for  the  first  time,  the  elements  remaining  in 
the  variable  domains  are  all  solutions  of  the  constraint.  As  a  consequence,  narrowing  some  domain  later  does 
not  require  additional  work. 
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Proposition  5  (Property  of  ICA2).  Let  S  =  {ci,...,Cm}  he  a  set  of  constraints,  and  B  a  box.  Then, 
ICA2(5,  {B})  C  lnnero(B  n  (1  •  ■  •  D  Pm)- 

Inclusion  in  Proposition  5  may  be  replaced  by  an  equality  provided  the  operators  I  Cl  used  are  all  optimal. 
Algorithm  2.  ICA2  -  Inner  contracting  algorithm  for  ci  A  •  •  •  A  Cm 

1  ICA2(m;5  =  {ci,...,c„,}  CC,AeP(I?)iOUt:WeP(IS)) 

2  begin 

3  if  (iS  7^  0)  then 

<  B  ^ —  0 

■5  foreach  D  £  A  do 

7  endforeach 

8  return  (1C A2(5  \  {ci},jB)) 

(■  else 

10  return  (A) 

n  endif 

12  end 


4  Introducing  Quantifiers 

Given  a  n-ary  constraint  c{xi, . . .  ,Xn)  and  a  box  B  =  Ii  x  •  •  •  x  In,  applying  the  inner-contracting  operator 
IClc  to  B  gives  a  set  of  boxes  U  =  {B[, J3' }  where  each  B'.  =  J9i  x  •  ■  •  x  is  a  sub-box  of  B  such  that: 
Vri  €  X>i, . . . ,  Vr„  e  :  c(ri, . . . ,  rn)  does  hold. 

Therefore,  solving  a  constraint  of  the  form  Vxk :  c{xi,  ...,Xn)  consists  in  retaining  only  boxes  B'  -  {Di  x 
-  •  •  X  Dn)  of  li  such  that  Dk  =  Ik- 

Given  V  the  universally  quantified  variable,  Algorithm  ICASg  described  by  Algorithm  3  narrows  domains  of 
all  variables  occurring  in  a  constraint  c  but  v,  and  is  an  optimal  inner-approximation  operator  for  the  constraint 
Vn:  c. 

An  efficient  algorithm  (ICAbSc)  computing  an  inner-approximation  operator  for  constraint  c  may  be  derived 
from  Algorithm  3  by  replacing  OClc  by  the  outer-box  approximation  operator  OCbe.  Note  that  optimality  is 
then  lost.  In  the  same  way,  replacing  IClc^  by  ICAba^  in  ICA2  leads  to  Algorithm  ICAb4  computing  an  inner 
approximation  for  the  constraint  Vn :  ci  A  •  •  •  A  c^. 


Algorithm  3.  ICA3e  -  Inner  contracting  algorithm  for  Vn:  c 

1  ICA3c(m:  B  e  I?,t;  e  Vr;  out:  W  G  P(K)) 

2  begin 

£>-i-OClo(B) 

0  if  (B  0  and  -iCanonicahfZ)))  then 

r  (Di,£)2)G-Split„(£)|„,B) 

8  W  G- WUlCA3c(Bi,n)UlCA3c(B2,n) 

9  endif 

10  return  (W) 

11  end 

I  The  Split„  function  used  in  the  algorithm  splits  in  two  intervals  one  of  the  non-canonical  domains  of  D.  Domain  Domn(v)  is  never  considered  for 
splitting.  In  the  same  way,  Canonicalv  tests  canonicity  for  all  domains  but  the  one  of  variable  v. 
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5  An  Application  to  the  “Virtual  Cameraman  Problem” 


Jardillier  and  Languenou  [9]  devised  the  prototype  of  a  declarative  modeller  allowing  an  artist  to  specify  the 
movements  of  a  camera  using  the  vocabulary  proper  to  the  field  (panoramic  shot,  travelling, ...  ).  The  movements 
description  is  translated  into  a  constraint  system  where  the  time  t  is  a  universally  quantified  variable.  To  solve 
a  system  of  the  form  Vt:  ci  A  •  •  •  A  Cm,  they  use  Algorithm  EIA4  which  computes  an  inner  approximation  by 
decomposing  the  initial  domain  It  of  t  into  canonical  intervals  I^,  ...  ,If,  and  testing  whether  ci  A  •  •  •  Ac^  does 
hold  for  the  boxes  /i  x  •  •  •  x  x  •  •  •  x  7„, . . .  ,  /i  x  ■  •  •  x  /j’  x  •  •  •  x  These  evaluations  give  them  results  in  a  three¬ 
valued  logic,  namely  (true,  false,  unknown) .  Boxes  labeled  true  contain  only  solutions,  boxes  labeled  false  contain 
no  solution  at  all,  and  boxes  labeled  unknown  are  split  recursively  and  re-tested  until  they  may  be  asserted  true 
or  false,  or  canonicity  is  reached.  Retained  boxes  are  those  verifying:  Vj  €{!,...  ,p}:  eval{ciA  -Ac,„}(7i  x  •  •  •  x 

X  •  •  ■  X  7„)  =  true. 

We  have  devised  a  new  modeller,  replacing  EIA4  by  ICAb4.  Experimental  evidences  show  that  it  is  up  to  40 
times  faster  than  the  prototype  described  in  [9]  on  a  set  of  benchmarks.  Moreover,  ICAb4  splits  the  explored 
space  in  bigger  consistent  chunks  than  EIA4,  and  avoids  losing  time  splitting  extensively  non-solution  areas. 
Figure  1  compares  graphically  the  splitting  sequence  for  the  explored  space  of  circle2,2,  a  collision  problem: 
given  points  Bi  and  B2  moving  along  circles  of  radius  ri  and  ra,  find  all  the  possible  locations  of  a  point  A  such 
that  Bi  (resp.  B2)  is  always  at  a  distance  greater  than  di  (resp.  6.2)  from  A.  Constraints  to  solve  are  then  of 
the  form:  V0  E  [-tt,  +7r] :  a/ (n  sm(ff)  -  x)^  +  (n  cos(d)  -  y)^  ^  di.  In  the  figure,  the  darker  the  area,  the  later 
its  exploration  was  achieved.  White  areas  stand  for  non-solution  sets. 


EIA4  ICAb4 


Fig.  1.  Comparison  of  the  solutions  generation  order  for  c«rcle2,2 


6  Conclusion 

Unlike  the  methods  used  to  deal  with  universally  quantified  variables  described  in  [7],  the  algorithms  presented 
in  this  paper  are  purely  numerical  ones  (except  for  the  negation  of  constraints).  Since  they  rely  on  “traditional” 
techniques  used  by  most  of  the  interval  constraint-based  solvers,  they  may  benefit  from  the  active  researches  led 
to  speed-up  these  tools.  However,  they  are  for  the  moment  limited  to  only  one  universally  quantified  variable 
while  the  methods  of  [7]  deal  with  many  variables  and  quantifiers  (existential  and/or  universal).  To  achieve  such 
a  generalization  is  a  major  direction  for  future  researches. 
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Abstract.  In  this  paper  we  examine  a  technology  for  solving  problems  on  graphs  in  the  constraint  pro¬ 
gramming  framework  called  Subdefinite  Models.  We  describe  in  brief  the  mechanism  of  constraint  propaga¬ 
tion  underlying  it.  We  present  in  details  facilities  for  specification  of  graph  problems  as  subdefinite  models. 
We  discuss  a  class  of  graph  problems  with  emphasizing  on  ones  having  not  been  discussed  before. 


1  Introduction 

Constraint  programming,  a  popular  paradigm  in  computer  science,  allows  one  to  solve  a  large  class  of  problems 
from  different  fields  stated  as  Constvaint  So,tisfo,ction  Problems  [1].  Subdefinite  models  apparatus,  proposed 
by  Narin’yani  [2]  and  developed  in  our  works  [3,4],  is  a  powerful  constraint  programming  framework.  The 
extension  of  this  framework  for  solving  problems  on  graphs  is  discussed  in  the  paper.  In  section  2  the  mechanism 
of  constraint  propagation  in  subdefinite  models  enriched  with  facilities  for  representation  and  processing  of 
compound  objects  like,  graphs  is  described.  In  the  third  section  the  specification  of  some  graph  problems  in  this 
framework  is  presented. 


2  Constraint  Propagation  Based  on  Subdefinite  Models 

2.1  Constraint  Satisfaction  Problem 

Definition  1.  A  Constraint  Satisfaction  Problem  (CSP)  is  a  pair  {V,C),  where 

-  V  is  a  (finite)  set  o/ variables,  each  variable  v  £  V  has  its  domain  Dy, 

-C  =  ljZ^,Cmis  a  (finite)  set  of  constraints,  each  constraint  c  €  Cm  has  m  arguments  Arpc  :  m)  -¥ 

V  and  an  m-ary  relation  over  the  arguments  domains:  Rc  C  x  •  •  •  x  DArg^{m)- 

A  solution  of  CSP  {V,  C)  is  an  assignment  of  a  value  e  Dy  to  each  variable  v  £V  such  that  for  all  c  £  C 
(let  C  £  Cm)  (Oylrp^(l),  .  .  .  ,  aArgc{m))  ^  Rc- 

Clearly,  we  do  not  have  a  universal  algorithm  for  finding  of  all  solutions  of  a  given  CSP.  (In  the  case  of 
finite  domains  we  deal  with  an  NP-hard  problem  and  there  are  universal  algorithms,  like  ”generate-and-test” 
or  ^backtracking  ,  for  solving  CSPs  over  such  domains.)  However,  there  are  universal  algorithms  for  finding  of 
an  ’’approximation”  of  the  set  of  all  solutions  of  a  CSP.  The  algorithms  are  known  as  ’’constraint  propagation” 
algorithms.  To  describe  our  variant  of  one  of  such  algorithms,  firstly,  we  should  define  some  additional  notions. 

2.2  Subdefinite  Extensions 

Definition  2.  Given  a  domain  D,  its  subdefinite  extension  (SD-extensionj  is  a  domain  (denoted  by  *D)  with 
the  following  properties: 

-  *D  is  a  finite  set  of  subsets  of  D, 

-  0  and  D  are  elements  of  *D, 

-  if  d'  and  d"  belongs  to  *D,  then  d'  nd"  £*D. 
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Elements  of  an  SD-extension  will  be  denoted  by  bold  letters.  Any  subset  D'  of  D  can  be  approximated  in  the 
SD-extension  *D  as  follows: 

app*D{D’)=  Pi  d. 

D'Cde-r? 

Example  1.  Let  D  be  a  finite  domain.  Then  we  consider  *D  =  2^,  the  set  of  all  subsets  of  D,  as  an  SD-extension 
of  the  domain  D. 

The  notion  of  the  SD-extension  allows  one  to  apply  a  single  constraint  propagation  algorithm  not  just  to 
finite  domains,  but  also  to  infinite  or  continuous  ones. 

Example  2.  Let  TZ  be  the  set  of  all  real  numbers.  Consider  its  finite  subset  Rq.  An  R^-bounded  interval  x  =  [x,x] 
(where  x,x  £  i?o  U  {-oo,-l-oo})  is  defined  as  a  set  {x  £  72.  |  x  <  a:  <  x}.  The  set  of  all  7?o-bounded  intervals 
will  be  denoted  by  m{Ro).  It  is  easy  to  see  that  nZ{Ro)  is  an  SD-extension  of  72. 

Example  3.  Let  Z  be  the  set  of  all  integer  numbers.  Then  one  can  build  an  SD-extension  of  Z  either  as  in 
example  1  (for  a  finite  subset  of  .E),  or  as  in  example  2. 

Example  4-  Let  Di,...,  Dn  be  a  set  of  domains,  and  let  *i7i , . . . ,  be  their  SD-extensions.  Consider  a  com¬ 
pound  domain  D  —  Di  x  ...  x  Dn-  One  can  build  an  SD-extension  *D  of  the  domain  D,  as  follows: 

*D  =  *DiX  ...x  *Dn. 

It  satisfies  all  the  conditions  from  definition  2.  Since  elements  of  an  SD-extension  are  sets,  any  element  d  £ 
will  be  considered  hereinafter  both  as  a  tuple,  d  =  (di , . . . ,  d^),  and  a  set,  d  =  di  x  . . .  x  d„.  We  hope  that 
this  notation  will  not  confuse  the  reader. 

Other  examples  of  SD-extensions  of  different  domains  can  be  found  in  [4]. 

2.3  Filtering 

Definition  3.  Let  Di,...,Dn  be  domains,  *Di,. . . ,  he  their  SD-extensions,  and  R  be  a  relation  over  them 
(i.  e.  R  C  Di  X  ...  X  Dn).  The  filtering  function, 

Tr:*DiX  ...X  *Dn  -^*DiX...x  *D„, 

of  the  relation  R  in  SD-extensions  of  domains  is  defined  as  follows: 

.FK(di,..  .,d„)  =  app.i)jx„,x*£)„(7?ndi  x  . ..  x  d„). 

The  meaning  of  the  filtering  function  of  the  relation  R  is  the  following.  Let  d,  be  the  set  of  admissible  values 
of  variable  Xi  (for  *  =  1, . . . ,  n)  and  values  of  xi , . . . ,  x„  are  connected  by  the  relation  R.  The  filtering  function 
Tr  ’’filters”  the  set  of  admissible  values  for  each  variable,  excluding  values,  which  are  known  to  be  incompatible 
in  the  sense  of  relation  R  with  values  of  other  variables. 

Example  5.  Let  Z)i,...,Z7„  be  finite  domains,  *Di  =  2^‘  (*  =  l,...,n)  be  their  SD-extensions,  and  R  C 
Di  X  . . .  X  D„  be  a  relation  over  domains.  Then 

:FR(di,...,d„)  =  (7ri(i2ndi  X  ...  X  d„),...,7r„(i2ndi  X  ...  X  dn)), 

where  Tri{X)  is  the  z-th  projection  of  relation  X. 

Example  6.  Let  72  be  the  set  of  all  real  numbers,  and  2’72(i?o)  be  the  set  of  all  i2o-bounded  intervals  (see 
example  2)  for  some  finite  Rq  <Z1Z.  Consider  the  relation  add  C  72®,  where  (x,y,z)  £  add  iS  x  +  y  =  z.  The 
filtering  function  of  add,  .7^add>  defined  according  to  definition  3  as  follows: 

•^add(^>y>*)  = 

[max{y,  (z  -  x)“},min{y,  (z  -  x)+}], 

[max{z,  (x -t- y ) “  } ,  min{z,  (x -1- y)+ }]) . 

x'^  =  min{y  £  jRq  U  {-cso,  4-oo}  |  a:  <  y}, 
x~  =  max  {y  £  Rq  U  {-oo,  -foo}  |  a:  >  j/}. 


Here 
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n-i  effective  algorithms  for  filtering  functions  of  other  relations  over  real  numbers 

(like  x*y  -  z  ,  or  ”sin(x)  =  y” ,  etc.)  in  interval  SD-extension  lUiRo)  of  TZ. 

Example  7.  Consider  an  arbitrary  domain  J9,  and  its  vector-domain  A, 

A  =  I>x...xD  =  £>" 

^ — V - ' 

n 

for  soine  positive  integer  n,  and  the  domain  of  all  integer  numbers  2.  Let  *D  be  an  SD-extension  of  the  domain 
D,  A  be  the  following  SD-extension  of  the  compound  domain  A  (the  same  as  in  example  4): 

*A  =  *Dx  ...x*D  =  (*D)", 


and  *Z  be  an  SD-extension  of  Z.  Consider  the  following  relation 

index  C  Ax  Z  x  D, 

where  {a,i,  e)  G  index  iff  the  i-th  element  of  vector  o  is  e,  i.  e.  a  =  (ei , . . . ,  e„),  and  =  e.  The  filtering  function 

•^index  relation  index,  is  defined  according  to  definition  3  as  follows.  For  a  =  (ai  a^,!  G  i  p  *Z 

and  e  G  v  i,  •  ■ ,  n;  ^  i  c 


‘^index(®’  L ®)  ~  j  i  > g  ); 


where 


{(ai,...,aj_i,aine,ai+i,...,an),  if  i  fl  {1, . . .  ,n}  =  {il, 

0,  ifin{l,...,n}  =  0,  ^ 

a,  otherwise 

i'  =  i  n  app,_g:({j  |  a*  n  e  7^  0}), 
e' =  enapp.£,(|Jai). 

i6i 

One  can  easily  extend  the  previous  example  to  an  indexation  of  a  matrix.  We  omit  the  corresponding  example 
due  to  the  limitation  of  the  paper’s  size.  However,  we  will  use  a  relation 

index2  C  x  Z  x  Z  x  D, 

and  its  filtering  function 

^index2  =  x*Zx*Zx*D-^  x*Zx*Zx*D 

for  an  indexation  of  a  matrix  with  the  size  k  x  I  for  positive  integers  k,  I . 


2.4  Subdefinite  Models 

Definition  4.  Let  (V,  C)  be  a  CSP.  A  subdefinite  model  of  CSP  [V,  C)  (where  V  =  {v,,  ...,Vn})  is  defined  as 
follows: 

-  for  the  domain  of  each  variable  v  e  V,  its  SD-extension  is  built;  denote  the  compound  domain 

X  ...  X  by  Dv  and  its  SD-extension  *Dy^  x  ...x  by  *Dv  ; 

—  for  each  constraint  c  £  C  (let  c  G  Cm ),  a  filtering  function 

'■  *DArgc{l)  X  ...  X  *D *^4rsAl)  X  ...  X  *DArg^{m) 

of  its  relation  Rc  is  built. 

To  simplify  the  notation,  instead  of  we  will  consider  the  function 

Tt  ■  *Dv  ^  *Dv 

defined  as  follows.  Let  Arg^  [j)  =  v;.  for  j  =  l,...m,  and  (dj, , . . . ,  d^^ )  = 

=  (e,, , . . .  ,ei^).  Then  ...  ,dn)  —  {ti, ...  where 

^  {*1)  •  •  • )  *to}) 

*  \  flj, otherwise. 
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The  algorithm  of  constraint  propagation  in  a  subdefinite  model  of  CSP  (V,  C)  (where  V  =  {vi , . . , ,  t>n})  is 
defined  as  follows. 

Definition  5  ((Constraint  Propagation  Algorithm)). 

At  the  t-th  step,  we  will  denote 

d(*)  G  *Dv  -  the  vector  of  subdefinite  values  of  variables  V, 

Q(i)  CC  -  the  set  0/ active  constraints. 

Step  0.  Let  =  (D^i,...,L)^„), 

Q^^y=c. 

Step  1 4- 1.  If  =  0,  then  STOP.  Otherwise,  choose  c  €  and  let 

d(‘+^)  =:r+(dW), 

=  g{*)  \  {c}  U  {c' e  (7  I  (3i)  Argc'(i)  =  Vj  and  df  ^  d5‘+')}. 

The  properties  of  the  constraint  propagation  algorithm  are  summarized  in  the  following  proposition  (see  [3] 
for  proof). 

Proposition  1.  In  terms  of  the  previous  definition,  the  following  assertions  are  valid: 

1.  Constraint  propagation  algorithm  in  subdefinite  models  always  terminates.  The  number  of  its  steps  is  less 

than  \C\  where  L{*Dv)  is  the  length  of  the  maximal  decreasing  (with  respect  to  ”C”)  chain  of 

different  elements  of  *Dy . 

2.  If  a  =  (ovi )  •  •  -  >  )  is  0.  solution  of  CSP  (V,C),  then  a  G  d*,  where  d*  is  the  vector  of  subdefinite  values 

of  variables  V  at  the  last  step  of  the  algorithm. 

3  Graph  Problems  as  CSPs 

For  considering  various  kinds  of  problems  on  graphs  we  will  discuss  the  representation  of  a  graph  structure  in 
a  CSP.  Below  we  briefly  redefine  the  common  notions  of  graph  theory. 

Definition  6.  A  directed  weighted  graph  is  a  pair  {V,E),  where  V  is  a  finite  set  0/ vertices  of  the  graph,  and 
E  CV  X  V  X  72.+  (where  72+  is  the  set  of  all  positive  real  numbers)  is  a  set  0/ edges  of  the  graph.  An  element 
{i,j,w)  G  E  denotes  an  edge  from  vertex  i  to  vertex  j  with  weight  w  >  0.  We  suppose  that  there  exists  at 
most  one  edge  between  two  vertices,  i.  e.  if  {i,j,w)  G  E,  (i',j',w')  e  E,  i  =  f,  and  j  =  j',  then  w  =  w'.  For 
simplicity,  we  will  suppose  that  V  is  a  subset  of  natural  numbers:  V  —  {1,2,...,  m} . 

An  undirected  weighted  graph  will  be  considered  here  as  a  kind  of  directed  weighted  graph  G  =  (V,  E),  where 
the  relation  E  is  irreflexive  and  symmetric  for  the  first  and  the  second  arguments,  i.  e.  if  {i,j,w)  G  E,  then 
ij,i,w)  G  E,  and  the  edge  {i,i,w)  does  not  belong  to  E  for  any  i  and  w. 

The  adjacency  matrix  of  the  graph  G  is  a  real  non-negative  matrix 
M  G  72"*’^™.  An  element  mij  of  the  matrix  M  is  the  weight  of  the  edge  frorn  vertex  i  to  vertex  j.  If  mtj  =  0 
then  there  is  no  edge  from  vertex  i  to  vertex  j  in  the  graph  G.  Clearly,  the  adjacency  matrix  of  an  undirected 
graph  is  a  symmetric  matrix  with  zeros  on  the  main  diagonal. 

3.1  Subdefinite  Graph 

Since  we  deal  with  subdefinite  values  in  a  CSP,  consider  the  advantages  of  applying  the  subdefiniteness  to  the 
graph  representation. 

Let  a  graph  G  =  (V,E)  be  represented  in  a  CSP  by  its  adjacency  matrix  M.  For  this  reason,  we  define  an 
SD-extension  of  the  domain  as  (7:72(iio))’"^’"  (see  example  2)  for  some  finite  real  subset  Rq.  In  this  case, 

we  can  use  subdefinite  values  (iJo-bounded  intervals)  for  the  representation  of  weights  of  edges.  This  means  that 
we  deal  with  a  graph,  which  has  subdefinite  edges.  If  the  subdefinite  weight  of  an  edge  contains  0,  then  this 
edge  can  be  absent  in  the  graph.  Otherwise,  the  edge  exists  in  the  graph,  but  its  weight  is  subdefinite,  i.  e.  only 
partially  known. 

One  can  use  only  defined  (precise)  values  in  an  adjacency  matrix,  of  course,  aind  therefore  one  can  deal  with 
fully  defined  graph.  However,  the  possibility  of  the  representation  of  subdefinite  graphs  allows  one  to  specify 
and  solve  a  much  more  broad  class  of  graph  problems.  Below  we  consider  various  problems  on  graphs  and  their 
representations  as  CSPs.  Also  we  emphasize  problems,  which  have  not  been  discussed  previously  in  the  graph 
theory. 
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3.2  A  Path  in  a  Graph 

Definition  7.  Given  a  directed  weighted  graph  G  =  (V,E)  and  two  of  its  vertices  i,j  e  a  path  between  i 
and  3  p{i,3)  ts  a  sequence  of  vertices  iuh, . . .  ,ii,  where  h  =  i,  ii  =  j,  andforallk  =  l,...,l-l  there  exists 
an  edge  tn  the  graph  G  between  vertices  ik  and  h+i,  i.  e.  there  exists  w>0  such  that  iik,ik+i,w)  G  E.  The 
weight  of  the  path  p{i,j)  =  ii,  i2j  •  •  •  j  i;  is  the  sum  of  weights  of  its  edges. 

Consider  the  specification  of  a  CSP  for  searching  a  path  in  a  graph.  Let  a  graph  G  =  {V,  E)  be  represented 
by  Its  adjacency  matrix  M  can  represent  a  path  from  vertex  i  to  vertex  j  as  a  vector  of  vertices 

P  G  F”*.  The  size  of  the  vector  is  equal  to  m  (the  number  of  vertices  of  the  graph),  but  only  first  /  elements  are 
meaningful.  The  specification  of  the  problem  for  searching  a  path  in  a  graph  is  performed  with  the  use  of  index 
and  index2  relations  discussed  in  the  previous  section  of  the  paper.  The  first  element  of  vector  P  is  equal  to  i: 

index(P,  l,i). 

Each  next  element  of  P  should  be  connected  with  the  previous  one  by  an  edge.  This  condition  is  represented 
by  the  following  set  of  constraints.  Let 

index(P,  k,u) 

for  some (1  <  <  m),  then 

pndex(P,  A;  +  1,  u), 
u  =  j  or  <  index2(M,u,t;,t0), 

[  ui  >  0. 

The  constraints  above  are  used  to  specify  a  CSP  for  searching  a  path  in  a  graph.  One  can  easily  add  to  this  CSP 
other  constraints  expressing  the  weight  of  a  path  and  find  the  path  with  minimal  weight  (see  [5]  to  learn  about 
the  constraint  propagation  algorithm  for  searching  an  optimal  solution  of  a  CSP).  Here  we  want  to  emphasize 
that  one  can  solve  problem  of  searching  an  optimal  path  in  a  graph  with  subdefinite  (partially  known)  edges 
or  edges  with  subdefinite  weights.  For  example,  we  have  specified  and  solved  the  Travelling  Salesman  Problem 
with  subdefinite  data  using  the  tools  described  above. 


3.3  A  Spanning  Tree  of  a  Graph 

Definition  8.  Given  an  undirected  weighted  graph  G  =  {V,E),  its  spanning  tree  is  a  graph  S{G)  =  {V,E'), 
where  E'  C  E,  and  S (G)  is  a  tree  ( a  connected  acyclic  graph ).  '  ’ 

There  is  an  equivalent  definition  of  a  tree  in  graph  theory.  In  our  terms  it  sounds  as  follows:  an  undirected 
weighted  graph  G  =  (F,  E)  is  a  tree  iff  it  is  connected  (i.  e.  there  exists  a  path  between  each  pair  of  its  different 
vertices),  and  \E\  -  2(|y|  -  1). 

We  need  two  groups  of  constraints  to  specify  a  spanning  tree.  The  first  one  is  the  condition  E’  C  E.  Let 
graphs  G  =  {V,  E)  and  S{G)  =  (F,  E')  be  represented  by  their  adjacency  matrices  M  and  M'  respectively.  Then 
the  condition  may  be  specified  as  follows: 


m'ij  =0  or 

for  all  Ly  =  l,...,m. 

The  second^  group  of  constraints  is  a  condition  that  S (G)  has  to  be  a  tree.  Since  a  tree  is  a  connected 
graph,  we  specify  the  existence  of  a  path  between  each  pair  of  different  vertices  in  S{G).  The  corresponding 
^oup  of  constraints  was  discussed  in  the  previous  subsection.  The  only  we  need  to  specify  else  is  the  condition 
\E  I  -  2(m  -  1).  Clearly,  \E'\  is  equal  to  the  number  of  positive  elements  of  the  matrix  M' . 

One  of  the  popular  graph  problems  is  a  building  of  a  spanning  tree  of  a  given  undirected  weighted  graph  with 
minimal  sum  of  weights  of  its  edges.  We  can  easily  specify  and  solve  such  problem  as  a  CSP  using  constraints 
defined  above.  Moreover,  we  can  solve  this  problem  with  additional  constraints  on  degrees  of  vertices- of  the 
spanning  tree.  In  our  terms,  the  degree  of  vertex  i  in  the  graph  G  represented  by  its  adjacency  matrix  M  is 
equal  to  the  number  of  positive  elements  in  i-th  row  (or,  equivalently,  in  i-th  column)  of  the  matrix  M.  Since 
we  can  deal  with  subdefinite  values,  these  degrees  can  be  given  as  integer  intervals.  As  far  as  we  know  such 
kind  of  graph  problems  has  not  been  discussed  before  in  the  graph  theory.  A  detailed  examples  presentation 
and  obtained  performances  characteristics  will  be  presented  in  the  full  version  of  the  paper. 
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4  Conclusion 

We  have  solved  all  the  problems  on  graphs  discussed  in  this  paper  using  constraint  programming  environment 
NeMo+  [6]  developed  in  our  institutes.  The  obtained  results  allow  us  to  hope  on  successful  application  of 
proposed  techniques  for  solving  a  large  class  of  graph  problems. 

Our  future  work  will  aim  to  extend  the  class  of  graph  problems  and  to  propose  new  constraint  programming 
techniques  for  its  solving. 

The  authors  are  indebted  to  Sergei  Sannikov,  a  student  of  Novosibirsk  State  University,  who  have  taken  part 
of  the  coding  of  some  of  these  problems  in  NeMo+,  and  to  the  referees  for  helpful  comments  on  the  paper. 
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Abstract.  Extensional  Set  (XS)  library  is  an  extension  of  BOLTS'  which  solves  set-theoretic  constraints 
over  extensional  sets  containing  variables  with  numeric  domains.  To  efEciently  process  such  a  class  of  sets 
domains,  XS  library  employs  a  constraint  programming  method  called  Subdefinite  Computations.  Within 
that  framework,  a  domain  representation  and  an  approximate  unification  algorithm  are  proposed.  The 
abilities  of  the  library  are  illustrated  by  a  geometric  application. 


1  Introduction 

Because  people  usually  express  their  knowledge  in  an  implicit  way  employing  partial  information,  the  computer 
needs  a  special  knowledge  representation  in  order  to  “understand”  such  partial  specifications.  Few  years  ago  in 
the  field  of  Constraint  Programming  (CP),  it  has  been  proposed  to  simply  add  a  control  mechanism  to  these 
specifications  provided  they  are  sufficiently  formal. 

During  recent  twenty  years  Constraint  (Logic)  Programming  has  developed  a  number  of  methods  and  tools 
processing  numeric  data  ranging  from  arc-consistency  for  finite  domains  [9]  to  box-consistency  for  interval 
domains  [12].  However,  constraint  programming  systems  which  process  sets  are  not  very  numerous  [13,8,4,5, 
14].  A  related  research  area  is  program  analysis  which  employs  sets  to  automatically  infer  various  properties  of 
programs  [6, 2, 1].  Finally,  in  the  imperative  environment,  sets  are  most  significantly  supported  in  the  language 
SETL  [11]. 

With  respect  to  CP  classification,  Subdefinite  (SD)  compuatation  are  a  consistency  technique  [10].  Given  a 
set  of  constraints,  it  produces  a  compact  description  of  a  set  which  contains  all  the  solutions  to  the  constraints. 
In  Section  3  SD  computations  are  described  in  more  details. 

ECLTS'  is  a  CLP  system.  It  allows  users  to  program  constraint  satisfaction  techniques  directly  at  the 
language  level.  The  paper  discusses  these  facilities  (Section  2)  and  a  technique  of  implementation  of  SD  com¬ 
putations  in  ECL  PS  (Section  3).  Section  4  describes  the  Extensional  Set  library  which  solves  constraints 
over  finite  extensional  sets  employing  the  proposed  implementation  technique.  Section  7  describes  a  geometric 
application  of  XS  library. 

2  ECL*PS« 

ECLTS®  is  an  abbreviation  for  ECRC  Common  Logic  Programming  System.  It  is  a  Prolog-based  system  whose 
aim  is  to  serve  as  a  platform  for  creating  various  extensions  of  logic  programming.  ECL*PS®  offers  two  data 
types,  meta-term  ^d  delayed  goal,  which  significantly  simplify  this  process.  Using  meta-attributes  and  delayed 
goals,  an  application  can  organize  additional  information  and  control  flows  in  its  own  way,  indenendentlv  of 
Prolog  standards. 

A  meta-term  consists  of  two  or  more  terms,  the  first  term  visible  to  “everyone”,  called  Prolog  value  of 
the  meta-term,  and  the  others,  called  meta-attributes,  visible  only  to  few  tools  which  convert  meta-terms  to 
standard  Prolog  data  and  vice  versa.  A  meta-term  is  written  like  T{namel:Tl,. . .}  where  T  is  its  Prolog  value,  T1 
is  its  meta-attribute  namel,  etc.  ’ 

Formally,  a  delayed  goal  is  a  Prolog  goal  whose  execution  has  been  delayed.  A  delayed  goal  represents 
an  action  that  should  be  done  in  the  future.  There  are  three  major  operations  with  delayed  goals:  creation, 
scheduling  for  execution,  and  execution  of  all  scheduled  goals.  A  delayed  goal  is  written  like  ’GQAL>  (G)  where  G 
is  the  goal  that  has  been  delayed  and  ’GOAL’  is  a  label  indicating  that  fact. 

°  This  project  is  supported  by  grant  98-06  from  Institut  Pranco-Russe  A.  M.  Liapunov  d’informatique  et  de 
math4matiques  appliqu^es. 
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3  SD  Computations 

SD  computations  has  been  introduced  by  A.  S.  Narinyani  in  early  1980’s  and  are  intensively  studied  by  our 
colleagues  from  A.  P.  Ershov  Institute  of  Informatics  Systems  and  Russian  Research  Institute  of  Artificial 
Intelligence. 

Let  us  take  some  signature  without  function  symbols,  with  predicate  symbols  {Q, . . variables  {x,y, . . 
constants  {a, . . and  some  interpretation  of  this  signature.  A  symbol  and  its  interpretation  identically  are 
typed  identically. 

A  constraint  is  an  atomic  formula.  A  constraint  satisfaction  problem  (CSP)  is  a  finite  set  of  constraints.  A 
solution  to  a  CSP  C  is  such  a  valuation  of  the  variables  under  which  each  constraint  in  C  holds.  The  value  a  of 
a  variable  x  is  extensible  to  a  solution  of  CSP  C,  if  there  is  a  solution  to  C  which  maps  x  to  a. 

Given  a  CSP  C,  SD  computations  produce  for  each  variable  x  a  set  of  values  which  contains  all  the  values 
of  X  extensible  to  a  solution  of  C.  Observing  the  traditions  of  CP,  such  a  set  of  values  is  called  a  domain  of  x. 
A  variable  and  its  domain  are  denoted  by  the  same  small  latin  letter. 

SD  computations  pay  much  attention  to  domain  representation  because  it  is,  in  fact,  a  question  of  effec¬ 
tiveness.  Simpler  domains  are  less  informative,  but  on  the  other  hand  they  are  processed  faster.  A  domain 
representation  is  a  function  (•)*  which  widens  an  arbitrary  domain  up  to  the  closest  representable  one.  ■ 

A  constraint  Q{x  y ..  ■)  defines  the  following  transformations  oi  x,  y,  . . 

a: Pri(Q  n  a:  X  2^  X  . .  .)*,  (1) 

y  <r-'?X2{Qf^xxyx  (2) 

which  are  called  calculation  functions  (Prj  is  projection  on  i-th  coordinate,  x  is  Cartesian  product).  The 
calculation  function  (1)  reads  x,y,  ...  and  writes  x,  the  calculation  function  (2)  reads  x,y,  ...  and  writes  y,  etc. 

Each  CSP  defines  a  network  of  calculation  functions  which  is  similar  to  networks  of  constraints  proposed  by 
other  authors  [9].  The  network  contains  nodes  of  two  types,  variables  and  calculation  functions,  and  naturally 
splits  into  star-like  segments.  The  center  of  each  star  is  a  calculation  function,  and  its  rays  reach  the  variables 
it  reads  and  writes. 

If  the  domain  of  a  variable  x  changes,  then  the  calculation  functions  that  read  x  propagate  this  change  to 
the  neighbours  of  x.  Using  the  data-driven  control  mechanism,  subdefinite  computations  propagate  this  wave 
of  domain  updates  through  the  network  of  calculation  functions  until  the  wave  expires. 

Implementation  in  ECL*PS®  In  what  follows  we  briefly  describe  how  data  types  from  Section  2  are  applied 
to  implementation  of  SD  computations.  Let  C  3  Q{xy...)  denote  the  CSP  to  which  SD  computations  are 
applied.  Each  variable  x  occurring  in  C  is  turned  into  a  meta-term  a;{sd:var(T3: ,  Fs)}  whose  meta-attribute  sd 
stores  the  domain  of  x  (the  term  Ta,)  and  a  list  of  calculation  functions  reading  x  (the  list  Fs). 

Each  predicate  symbol  Q  of  arity  n  is  associated  with  an  {n  +  l)-ary  Prolog  predicate  compute-q  whose 
intended  meaning  is  | 

q(l,Ti;,Tj,,.. .)  x  =  Pri{Qnxxy  X  ...)*, 

q(2,T*,T3,,...)  ?/ =  Pr2((3na:  X  2/ X  ...)*,  ... 

where  the  terms  Ti,,  Tj,,  etc.  denote  the  domains  of  a;,  2/,  etc. 

Calculation  functions  of  the  form  (1),  (2),  etc.  are  turned  into  delayed  goals  ’GOAL’  (coinput_q(l,a;,y, ...)), 
’GOAL’  (comput_q(2,a:,2/, ...)),  etc.  Figure  1  shows  an  encoding  for  a  calculation  function. 

4  Brief  introduction  to  XS  library 

Extensional  Set  (XS)  library  is  an  extension  of  ECL®PS®  which  solves  set-theoretic  constraints  over  extensional 
sets  containing  variables  with  numeric  domains.  The  particular  constraint  solver  for  numeric  data  (at  present, 
Interval  Domain  library  [15])  is  a  parameter  to  XS  library.  The  only  requirement  of  such  a  solver  is  that  it  offer 
access  to  lower  and  upper  bounds  of  numeric  domains  and  creation  of  numeric  domain  variables. 

Generally  speaking,  XS  library  computes  sets  of  ground  tuples.  A  tuple  is  a  term  constructed  of  numbers 
and  numeric  domain  variables  with  the  help  of  functors  (x/n)  (n  >  1).  Each  set  variable  is  associated  with  a  set 

^  In  the  Cartesian  products,  a  constant  a  is  replaced  with  {a}*.  If  a  is  not  finitely  representable,  then  {a}*  is  larger 
than  {o}. 
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q(l,  X,  Y,  ...):- 

make_suspension(q(l,  X,  Y,  . . . ) ,  3.  F)  , 

'/.  Ill 

extract(Y,  Y_dom,  Y_goals) , 

7.  [2] 

assign(Y,  Y_dom,  [FI Y_goals] ) , 

*/.  [3] 

extract (X,  X_dom,  X_goals) , 

*/.  [2*n] 

compnte.qd,  X_dom,  -Y_dom,  ....  Changed), 

7,  [2*n+l] 

(  van (Changed)  ->  true  ; 

7.  [2*n+2] 

assign(X,  X_dom,  []), 

7.  [2i‘n+3] 

schedule_woken(X_goals) , 

7.  [2*n+4] 

wake 

7.  [2*n+5] 

). 


Fig.  1.  A  simplified  code  of  a  calculation  function 


domain.  A  set  domain  consists  of  two  ground  sets  of  tuples  i  C  u.  If  this  domain  is  associated  with  a  variable 
X,  then  I  C  X  Cu. 

Each  constraint  over  sets  is  enclosed  in  curly  braces  and  states  either  equality  or  inclusion  (for  two  sets),  or 
membership  (for  a  tuple  and  a  set).  A  set  inside  such  a  constraint  is  specified  either  by  a  set  domain  variable, 
or  by  a  list  of  (not  necessarily  ground)  tuples,  or  by  an  expression  built  of  such  variables  and  lists.  Besides  that^ 
cardinality  of  a  set  can  occur  in  constraints  over  numeric  data. 

Equality  Keeping  two  sets  equal,  XS  library  modifies  set  domains  (if  at  least  one  of  the  sets  is  specified  by  a 
set  domain)  and  numeric  domains  (if  at  least  one  of  the  sets  is  specified  by  a  list  of  non-ground  tuples  containing 
numeric  domain  variables). 

Equality  of  a  set  domain  variable  and  a  list  of  tuples  is  maintained  by  two  delayed  goals  which  transfer 
information  between  the  set  domain  and  numeric  domains  inside  the  tuples  (if  any).  Enforcing  equality  of  two 
set  domain  variables,  XS  library  intersects  their  domains  and  unifies  the  variables  themself;  no  delayed  goals 
are  generated. 

The  following  example  shows  the  effect  of  stating  equality  of  two  sets; 

[eclipse  17] : 

{  [x(0,l),x(l,2),x(2,4)]  =  [x<0,X0),x(M,XN),x(2,X2)]  }. 

M  =  1 
XO  =  1 
XN  =  2 
X2  =  4 
yes . 

equality  constraint  between  two  sets  fails,  if  XS  library  is  able  to  determine  that  the  sets  are 
diiferent.  For  example,  the  following  query  fails: 

[eclipse  18]:  A  setdom  []  . .  [x(0,l)  ,x(l,2)]  ,  {  A  =  [x(N,N)  ,x(M.M)]  }. 
no  (more)  solution. 


Inclusion  Likewise  keeping  equality  between  two  sets,  keeping  set  A  included  into  set  B  updates  set  and  numeric 
domains  involved  into  specification  of  A,  B.  For  example: 

[eclipse  21]:  A  setdom  []  . .  [x(0,l)  ,x(l,2)  ,x(2,4)]  , 
f  [x(0,l) ,x(l,Xl)]  Bubseteq  A  }. 

A  =  A{[x(0,l),x(1.2)]..[x(0,l),x(l,2),x(2.4)]} 

XI  =  2 
yes. 

Set  expressions  A  set  can  be  specified  by  a  set  expression,  e.g. 

[eclipse  22]:  f  A\/[0,N]  =  [0,1,2]  },  {  A  A  [0,1]  =  []  }. 

N  =  1 

A  =  A{[2]} 
yes . 
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Membership  The  fact  of  presence  (absence)  of  a  particular  element  in  a  set  is  stated  by  membership  constraint. 
The  constraint  {  X  in  A  }  ({  not  X  in  A  })  tells  XS  library  “not  to  let  the  tuple  X  out  of  (into)  the  set  A”. 

Relating  a  tuple  and  a  set  of  tuples  by  membership  constraint,  one  is  able  to  model  application  of  a  function 
to  an  argument  as  follows: 

appCF,  I,  FI);-  {  x(I,  FI)  in  F  }. 

The  typical  usage  of  (app/3)  is  illustrated  by  the  following  problem  taken  from  [7]):  given  integer  m  <  n, 
find  such  a  function  /  that  f{i)  =  i  -  1,  if  i  €  [m  +  1,  n],  and  f{i)  =  f{f{i  +  2)),  if  *  e  [0,  m].  The  specification 
is  as  follows: 

findall(r(I,  FI),  (betweenCO,  N,  I),  FI  ♦*  0  . .  tf) ,  Up), 

{  F  =  Up  >, 

foralKl:  0.  .M,  app(F,  I)  *==  app(F,  app(F,  1+2)))  ), 
forall(I:M+l. .N,  app(F,  I)  +==  I-l  ). 

For  example,  if  M  =  6andN  =  9,  then  the  solution  is  F  =  F{[x(0,  6),  x(l,  6),  x(2,  6),  x(3,  6),  x(4,  6), 
x(5,  6),  x(6,  6),  x(7,  6),  x(8,  7),  x(9,  8)]}.  In  the  general  case,  XS  library  spends  approximately  0(m^ + 
n)  operations  on  each  instance  of  this  problem. 

5  Representation  of  Set  Domains 

Sets  are  so-called  content  addressable  structures.  In  an  imperative  environment,  data  of  that  kind  usually  is 
represented  by  hash  tables  which  make  access  to  data  having  specified  content  possible  in  nearly  constant  time. 
However,  in  logic  programming,  this  approach  is  likely  to  be  hard  to  stick  to. 

XS  library  transforms  lower  and  upper  bounds  of  set  domains  to  balanced  binary  trees  of  ground  tuples. 
Tuples  in  such  a  tree  are  arranged  with  respect  to  ^  defined  recursively  as  follows: 

1.  t  -<  u,  if  t,  u  are  numbers,  and  't<u, 

2.  i  -<  u,  if  f  is  a  number,  tt  is  a  tuple, 

3.  t  u,  if  t,  u  are  tuples,  and  t  is  shorter  than  u, 

4.  t  =x(. . .  t, . . .),  u  =x(. . .  Ui . . .)  are  of  the  same  length,  and  U  =  Ui  for  i  e  [1,  fe  —  1],  -<Uk- 

The  order  ^  agrees  well  with  unification  in  the  following  sense.  Let  t  be  a  non-ground  tuple.  Let  I  (respectively 
u)  be  the  ground  tuple  obtained  from  t  by  replacing  each  variable  v  in  t  with  the  lower  (respectively  upper) 
bound  of  the  domain  of  v.  It  is  easy  to  see  that,  if  a  1  or  w  -<  o  for  some  tuple  a,  then  unification  of  a  and  t 
will  fail. 

Such  a  representation  of  set  domains  is  advantageous  twofold.  First,  because  lower  and  upper  bounds  of 
domains  are  sorted,  all  operations  on  set  domains  take  linear  amount  of  time  (with  respect  to  the  sum  of  sizes 
of  involved  upper  bounds).  Second,  because  -<  and  unification  agree,  retrieving  from  a  set  all  the  instances  of 
a  non-ground  tuple  usually  requires  to  scan  only  small  part  of  the  set.  For  example,  if  X  is  a  constant,  Y  is  a 
variable  and  S  is  the  rectangle  [0,m]  x  [0,7],  then  XS  library  enforces  the  constraint  {  x(X,  y)  in  s}  in  0.03, 
0.05,  and  0.07  seconds  for  n=400,  800,  and  1600. 

6  Approximate  Set  Unification 

The  Set  Unification  problem  can  be  stated  as  follows:  given  two  sets  of  terms  (of  some  signature),  find  a 
substitution  which  makes  the  sets  identical.  The  Set  Unification  problem  has  been  proved  NP-complete.  Besides 
that,  even  if  two  sets  are  unifiable,  their  most  general  unifier  sometimes  is  not  enough  “informative” ,  e.g,  the  most 
general  unifier  of  {0, 1}  and  {x,y}  is  the  identity  substitution  {xlx,yfy}  which  bypasses  the  fact  of  unification. 
In  order  to  be  efficient,  (constraint)  logic  programming  systems  usually  restrict  the  class  of  processed  sets  [13, 
8,5]. 

XS  library  reduces  unification  of  sets,  each  specified  by  a  list  of  tuples,  to  unification  of  set  domain  variables 
which  are  related  to  these  lists  by  special  predicates  (st/2)  and  (ts/2).  The  predicates  approximate  calculation 
functions  of  the  following  relation  cr  between  finite  sets  and  lists: 

-  {(S) 01  s  =  {*!>•• =  [ii, •••,*«]) 'ti are  ground  tuples (i  e  [l,n])}. 

Though  computing  precisely  the  calculation  functions  of  a  seems  to  be  intractable,  some  larger  domains 
can  be  computed  efficiently.  Suppose,  the  lower  and  upper  bounds  of  the  set  domain  are  I,  u,  and  for  each 
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i  £  [1,  n]  the  tuple  ti  is  ground  iSi  <k.  In  the  notation  each  non-ground  tuple  is  treated  as  the  set  of  its  ground 
instances.  , 

Current  version  of  XS  library  recomputes  the  lower  and  upper  bounds  I,  u  of  the  set  domain  as  follows  (the 
predicate  (ts/2)):  ^ 

-  I  <-lU  {ti, . .  .,tk}, 

-  u^un({ti,...,4}uUr=fe+ati). 

-  if  |Z|  =  n,  then  u  1. 

That  procedure  may  compute  a  larger  set  domain  than  the  corresponding  calculation  function  would  do.  For 
example,  if  n  =  4,  ti  =  1,  *2  =  99,  ts  =  99,  U  is  a  variable  with  the  domain  [0, 9],  I  =  {9},  u  =  [0, 9]  U  {99},  then, 
after  a  call  to  (ts/2),  I  will  be  {1, 9, 99}  and  u  will  be  unchanged.  It  is  easy  to  check,  that  the  true  calculatiori 
function  will  set  I  and  u  to  {1,9,99}. 

The  non-ground  tuples  ti  {i  G  [/c  +  l,n])  are  iteratively  recomputed  according  to  the  following  rules  (the 
predicate  (st/2)): 

-  if  a  €  I,  a  £  ti^  for  a  unique  ia£[k  +  1,  n],  then  ti^  4r- a, 

~  ti  ■£-  ti  Du, 

-  if  |1|  =  n,  i  e  [l,n],  i  ^  j,  ti  is  ground,  then  tj  f-  tj  \  {ti}. 

The  computations  stop  when  the  tuples  stop  changing.  And  again,  the  above  procedure  may  compute  a  larger 
numeric  domain  for  some  variable  than  the  corresponding  calculation  function  would  do. 

7  Full  Minimum  Steiner  Trees 

We  turn  to  Mimmuin  Steiner  Tree  (MST)  problem  because  it  consists  of  non-trivial  numeric  and  combinatorial 
parts.  The  problem  is  stated  as  follows.  Given  a  set  R  of  required  vertices,  find  the  shortest  tree  among  trees 
spanning  JSU  5,  S  being  any  set  of  (Steiner)  vertices.  The  sets  R,  S  are  subsets  of  Euclidean  plane,  R  is  finite. 
Finding  the  MST  is  an  NP-complete  problem  [3]. 

We  focus  on  finding  the  MST  among  trees  spanning  Ru  S,  S  having  cardinality  |J?|  -  2,  and  call  it  a  full 
MST.  Let  R  and  S  be  sets  of  required  and  Steiner  vertices.  The  leaves  and  inner  vertices  of  the  full  MST  form 
respectively  R  and  S.  Each  inner  vertex  is  incident  to  3  edges  which  meet  at  the  angle  of  7r/3.  Thus  a  full  MST 
is  a  binary  tree  with  an  extra  vertex  attached  to  its  root. 

Let  R  y  S  =  {p*+i, . . .  ,^2^-2},  Pi  =  (xuPi).  The  topology  of  the  full  MST  is  specified  by 

famte  sets  {(*,fi)}i=fc+i  and  {(i,ri)}^_j.^^  of  arcs  mapping  each  inner  vertex  to  its  left  and  right  childs.  Because 
trees  are  acyclic,  the  sets  {hj^tk+i  {r,}?*^^^  of  left  and  right  childs  are  disjoint,  each  containing  exactly 
k-2  elements.  Note  that  points  in  S  can  be  numbered  so  that,  for  all  i,  k  <  i,  n  <  i. 

The  topology  of  the  full  MST  meets  the  following  mixture  of  constraints  over  set-theoretic  and  numeric  data. 

findalKxCl,  _)  ,  betveen(K+l,  2*K-2,  I)  ,  L) , 
findalKxCl.  _).  between(K+l,  2*K-2,  I) ,  R)  , 
term_ variables (L ,  Lchilds) , 
term_variables(R,  Rchilds) , 
forall(I:K+l. .2*K-2,  app(L,  I)  *=<  I-l) , 
forall(I:K+l. .2+K-2,  app(R,  I)  ♦=<  I-l), 
f  Lchilds  /\  Rchilds  =  []  } , 

#  Lchilds  *==  K-2,  #  Rchilds  *==  K-2, 

Functions  L,  R  niap  a  vertex  to  its  childs.  Lists  Lchilds,  Rchilds  specify  the  sets  of  respective  childs. 

4.V,  r  a  ®  (o^hPj)  be  the  polar  coordinates  of  pj  w.r.t  pi.  Then,  for  each  inner  vertex,  there  hold 

the  following  constraints.  • 

forall(I:K+l. .2*K-2,  ( 

app(X,  appCL.D)  *==  app(X,I)+app(Rh,app(L,I))fcos(app(Al,app(L,I))) , 
app(Y,  app(L,I))  ♦==  app(y,I)+app(Rh,app(L,I))*sin(app(Al,app(L,l))) , 
app(X,  app(R,I))  ♦==  app(X,I)+app(Rh,app(R,I))*cos(app(Al,app(R,I))) , 
app(Y,  app(R,I))  *==  app(Y,I)+app(Rh,app(R,I))*sin(app(Al,app(R,I))) , 
app(Al,app(L,I))  ♦==  app(Al.I)+pi/3, 
app(Al,app(R,I))  *==  app(Al,I)-pi/3 

)) 
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Functions  X,  Y  map  a  vertex  to  its  coordinates;  functions  Al,  Rh  map  a  vertex  to  its  polar  coordinates  w.r.t. 
its  ancestor.  Choose  p2fc-2  and  pi  to  be  the  root  and  the  extra  vertex  attached  to  it.  That  gives  the  last  two 
constraints. 

appCX,  2+K-2)  +==  app(X,l)+app(Rh,2*K-2)+cos(app(Al,2+K-2)) , 
appCY,  2*K-2)  ♦==  app(Y,l)+app(Rh,2*K-2)>i‘sin(app(Al,2+K-2)) 

The  constraints  describing  the  topology  and  coordinates  of  Steiner  vertices  define  a  space  of  feasible  trees 
which  can  be  explored  by  some  search  algorithm  in  order  to  find  the  full  MST.  Figure  2  shows  an  example  of 
the  full  MST  computed  by  XS  library  for  |iJl  =  16. 


Fig.  2.  A  Full  Minimum  Steiner  Tree 


8  Conclusion 

The  above  paper  presents  XS  library  for  logic  programming  system  ECL^PS®,  a  tool  solving  set-theoretic 
constraints  over  extensional  sets  containing  numeric  domain  variables. 

The  library  is  based  on  Subdefinite  computations.  To  solve  constraints  over  numeric  data,  XS  library  employs 
an  external  solver  (currently,  Interval  Domain  library)  which  is  a  parameter  to  XS  library.  Such  an  approach 
seems  more  reasonable  than  equipping  XS  with  its  own  solver  for  numeric  constraint  satisfaction  problems. 
In  order  to  efficiently  process  numeric  domain  variables  in  set  specifications,  XS  library  employs  an  approxi¬ 
mate  unification  algorithm.  This  set  unification  algorithm  makes  processing  non-ground  sets  efficient  which  is 
the  second  advantage  of  XS  library.  Further  development  of  the  library  is  directed  toward  efficient  low-level 
implementation  of  operations  on  set  domains. 

We  extend  our  thanks  to  A.  V.  Zamulin,  Yu.  A.  Zagorul’ko  from  A.  P.  Ershov  Institute  of  Informatics 
Systems,  T.  P.  Kashevarova,  A.  S.  Narin’yani  from  Russian  Research  Institute  of  Artificial  Intelligence  for 
invaluable  comments  and  discussion. 
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Abstract.  Every  science  and  technology  come  through  bifurcation  points  —  radical  changing  paradigms, 
some  revolutions  which  approach  are  not  realized  sometimes  even  on  the  eve  of  beginning  the  new  phase  of 
development.  The  appearance  of  a  computer  itself  fifty  years  ago  became  one  of  such  points  of  bifurcation, 
which  had  alternated  all  spectrum  of  high  technologies  of  the  second  half  of  the  twentieth  century.  But 
having  became  one  of  leading  industries,  the  information  technologies  are  coming  now  very  close  to  the 
first  in  their  short  history  radical  revolution  which  will  completely  change  "unshakable”  foundations  of  the 
modern  apparatus  of  the  Information  Technologies. 


Half  a  century  history  of  the  modern  Information  Technologies  (IT)  is  full  of  contrasts.  On  the  one  hand  we  see 
the  swift  development  of  hardware  with  its  unbelievable  gradient  of  upgrowth  —  about  dozen  times  per  year, 
which  is  impossible  for  any  other  field  of  industry.  On  the  other  hand  —  incompatible  to  this  rapid  progress 
conservatism  of  the  basic  principles  which  has  been  leading  to  more  and  more  dramatic  contrast  between  the 
IT  technical  possibilities  and  their  current  actual  level. 

During  their  short  history  the  Information  Technologies  have  been  developing  on  the  basis  of  the  central 
principle  of  Algorithm  and  four  closely  interrelated  key  corner-stones:  . 

-  Sequential  deterministic  process 

-  Modern  Object-Oriented  software  technology 

-  Von  Neumann  architecture  of  Computer 

-  Ttaditional  computational  mathematics. 

The  given  key  principles  seem  even  more  unshakable  now  than  five  decades  ago.  Their  procrustean  bed  has 
became  so  habitual  that  is  supposed  to  be  natural  and  the  only  one  possible,  in  spite  of  its  inborn  defects  which 
in  many  cases  are  close  to  absurd. 

It  is  obvious  that  the  real  world  organization  is  completely  different.  Each  its  component  —  an  elementary 
particle,  a  cell  in  organism,  a  human  in  community,  a  planet  or  galaxy  —  is  an  active  autonomous  entity  which 
participates  in  a  parallel,  asynchronous,  decentralized  process  of  interaction  to  other  active  entities  of  the  same 
level. 

The  modern  organization  of  IT  is  perfectly  opposite  to  this  natural  order:  it  is  trying  to  control  any  system 
from  a  unique  center  with  imperative  directions  which  define  who  and  in  what  order  should  act. 

This  dead-end  paradigm  blockades  development  of  all  main  IT  constituents:  the  computer  architecture  and 
software  technology,  organization  of  data  and  their  flows  in  communication  nets,  management  and  control  of 
complex  systems.  Multiple  attempts  of  its  reforming  have  not  led  to  a  radical  change  of  the  trajectory.  During 
the  last  decade  we  have  often  heard  that  IT  development  has  reached  a  stage  which  doesn’t  promise  new  "big 
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jumps”  (except  the  hardware  techniques)  —  its  task  is  limited  to  development  of  the  accumulated  experience 
and  expansion  of  its  application  sphere. 

But  it  is  not  true  at  all.  A  feeling  of  ’’current  foundations  for  ever”  is  very  typical  for  neighborhood  of 
bifurcation  points:  let’s  remember  the  very  beginning  of  60s  when  programming  in  code  seemed  the  main 
principal  form  of  IT  for  all  visible  perspective.  But  it  vanished  for  ever  just  in  a  few  years. 

Now  we  are  very  close  to  a  bifurcation  which  will  be  global  to  the  whole  IT  complex.  Qualitatively  novel 
technologies  have  been  formed  and  they  are  developing  very  fast.  They  are  based  on  non-algorithmic  data-driven 
process,  which  is  naturally  parallel  and  non-deterministic.  The  approaching  revolution  will  ensure  complete 
change  of  current  paradigm  up  to  radical  reform  of  the  computational  mathematics  apparatus,  which  has  been 
comparable  by  its  unshakableness  only  with  geography. 

To  estimate  the  IT  perspective  of  the  next  century  beginning  we  need  to  consider'  (at  least  roughly)  possible 
directions  of  development  of  the  following  three  aspects  of  the  whole  picture: 

A.  Evolution  of  the  knowledge  apparatus,  the  very  core  of  means  of  the  IT  intellectualization 

B.  Influence  of  this  process  on  the  further  intellectualization  of  IT 

C.  Novel  generations  of  applications  being  defined  by  the  progress  of  A  and  B. 

The  minimal  volume  of  this  material  is  limiting  its  content  with  a  ’’dotted”  and  very  subjective  discussion 
of  those  three  aspects  through  outlines  of  some  their  principal  constituents.  Of  course,  the  theme  of  this  paper 
needs  a  list  of  many  hundred  references,  —  because  of  that  I  should  limit  it  with  a  few  own  publications 
illustrating  some  points  in  this  discussion. 


1  Evolution  of  the  knowledge  apparatus 

The  knowledge  based  technology  is  still  very  young  and  only  reaching  the  threshold  of  real  formation.  It  has 
ahead  a  difficult  task  of  generalization  of  its  accumulated  reserve  of  ideas  and  experience,  which  should  be 
transformed  into  unique  and  powerful  apparatus. 

In  this  course  of  integration  the  traditional  components  are  beginning  to  be  completed  with  new  methods 
of  constraint  programming,  in  particular,  with  subdefinite  models  (nedoopredelennye  or  N-models  in  Russian) 
which  cover  all  principal  data  types  and  ensure  incorporation  of  more  and  more  powerful  means  of  automatic 
solution  of  computational  and  logic-combinatorial  problems  in  the  knowledge  apparatus. 

I  am  sure  that  the  knowledge  apparatus  has  one  more  —  strategic  —  horizon.  During  long  history  of  the 
mathematics  it  was  the  object  of  very  polar  judgments;  from  admiration  and  worship,  as  the  ultimate  truth, 
to  sharp  criticism  which  accuses  the  queen  of  sciences  in  sojourn  behind  of  border  of  abstraction,  very  far  from 
problems  of  the  real  world.  Seventeen  years  ago  I  proposed  a  NE-factors  term  [1,2]  for  notation  of  a  complex 
of  features  which  are  typical  for  the  human  knowledge  about  the  real  world  but  represented  rather  poor  in 
formal  systems  (incompleteness,  imprecision,  subdefinitehess,  incorrectness,  and  many  others).  It  is  possible  to 
presuppose  that  NE-factors  will  form  something  like  the  periodical  system  of  elements  for  the  future  real  world 
knowledge  apparatus. 

During  this  period  the  subdefiniteness  was  investigated  rather  thoroughly  that  led  to  creation  of  theory  and 
technology  of  mentioned  above  N-raodels  [3].  But  other  NE-factors,  which  are  closely  interconnected  and  play 
no  less  important  role  in  applications,  have  remained  practically  undeveloped  (minority)  or  unknown  at  all.  It 
seems  that  investigation  of  individual  NE-factors  with  construction  of  adequate  formal  means  as  well  as  their 
organization  in  unique  complex  will  play  for  IT  no  less  revolutionary  role  than  transition  from  the  alchemy  to 
the  modern  chemistry. 


2  Information  technologies  —  change  of  epochs 

The  development  of  the  knowledge  apparatus  exerts  constant  influence  on  forming  IT  new  generations  from  the 
basic  level  up  to  means  of  intellectualization.  Let’s  consider  briefly  some  of  main  tendencies  in  this  domain. 


2.1  End  of  the  Algorithm  Era 

The  Algorithm  was  the  fundament  of  the  programming  techniques  for  computers  of  von  Neumann  architecture 
from  the  very  beginning.  Nevertheless  from  the  middle  of  60s  many  attempts  to  develop  alternate  approaches 
has  taken  place.  First  of  all  it  was  related  with  research  in  Artificial  Intelligence  and  on  parallel  programming 
for  multiprocessor  computers  [4]. 
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But  qualitative  progress  here  is  ensured  by  the  apparatus  of  N-models  and  the  most  recent  works  on  the 
constraint  programming  because  they  are  based  on  a  decentralized,  multi-agent  data-driven  computational 
process  which  allows  implementing  any  software  system  in  form  of  a  structured  model  which  integrates  an 
hierarchical  complex  of  autonomous  active  components.  As  the  following  step  in  this  radical  transformation  it 
is  possible  to  transit  to  event-driven  process,  which  should  substantially  arise  the  level  of  associative  machinery 
organizing  the  computer  work. 

2.2  Technology  of  Active  Objects 

An  irhportant  direction  of  the  current  IT  progress  is  development  of  the  object-oriented  philosophy.  But  for 
the  present  this  approach  forms  only  the  base  of  the  future  technology  by  bringing  an  oo-program  more  and 
more  near  to  structured  Model  but  leaving  the  algorithmic  character  of  the  control  of  its  realization  without 
any  change. 

At  the  same  time  the  development  of  data-driven  and  event-driven  control  forms  the  next  generation  of 
IT  on  the  basis  of  active  autonomous  objects,  which  should  integrate  multi-agent  architecture,  the  constraint 
programming  and  the  N-model  apparatus.  Just  this  fact  will  allow  IT  to  build  systems  of  any  complexity 
ensuring  naturalness  and  reliability  of  their  functions.  ■ 


2.3  Novel  computational  mathematics 

The  modern  computational  mathematics  operates  with  a  few  hundred  of  different  methods  of  solution  for 
isolated  classes  of  particular  problems  representing  separated  islands  in  the  ocean  of  real  calculation  tasks.  This 
world  order  is  only  one  possible  from  the  point  of  view  of  islanders,  which  have  never  heard  of  existence  of 
continents. 

The  fundament  of  N-model  and  constraint  programming  apparatus  is  a  special  universal  process,  which 
extracts  the  whole  space  of  solutions  of  a  problem  and  can  work  with  both  definite  and  subdefinite  algebraic 
systems  in  which  subdefiniteness  may  be  referred  to  values  of  parameters  as  well  as  to  relations  over  them. 

This  radically  changes  the  very  paradigm  of  calculations.  Allowing  taking  off  principal  restrictions  of  tradi¬ 
tional  methods  it  ensures  a  jump  in  expanding  the  spectrum  of  solvable  problems  and  quality  of  obtained  results. 
The  novel  computational  apparatus  makes  possible  to  solve  reverse,  regression  and  optimization  problems  for 
which  in  many  cases  there  are  no  standard  numerical  methods.  Very  often  it  raises  in  dozen  times  the  efficiency 
of  calculation  in  correspondence  to  the  best-known  algorithms. 


2.4  Model  but  not  Algorithm 

The  novel  IT  paradigm  is  oriented  to  the  Model  and  direct  interaction  with  it.  This  for  ever  resolves  the  crucial 
conflict  of  Model  and  Algorithm:  in  10-15  years  the  Algorithm’s  fate  will  repeat  the  fate  of  assemblers  and 
programming  in  machine  code:  loss  of  today’s  key  positions  and  a  modest  place  in  a  thin  base  level  of  the 
computer  technology  of  the  near  future  [5] . 

For  many  classes  of  application  this  paradigm  has  already  proved  its  advantages  which  allow  the  user  to 
work  with  his  model  directly  without  any  traditional  go-betweens  in  form  of  methods,  algorithms  and  programs. 
And  it  makes  possible  to  combine  within  the  same  Model  any  combinations  of  different  formal  apparatus  — 
algebra,  logic,  sets,  etc. 

Not  being  related  with  the  algorithmic  mentality  the  new  organization  of  the  computing  process  in  the  form 
of  compressing  the  Model  space  on  the  base  of  data-driven  control  is  intrinsically  decentralized,  parallel,  non- 
deterministic  and  asynchronous  which  makes  it  naturally  and  easily  transportable  to  multiprocessor  computers. 

2.5  Parallelism 

During  last  decades  unsolvability  of  the  problem  of  parallelization  for  imperative  programs  has  been  forming 
an  insuperable  barrier  in  the  way  of  wide  propagation  of  multi-processor  computers.  By  now  the  software  and 
hardware  have  switched  their  places:  the  level  of  automatization  of  hardware  design  and  low  cost  of  chips  allow 
mass  production  of  computers  with  any  number  processors  but  parallel  software  has  kept  to  be  a  hard  problem 
which  is  solvable  only  by  high  class  specialists  and  only  in  some  special  cases.  In  the  new  IT  paradigm  the 
parallelism  stops  to  be  a  bottleneck  but  becomes  a  natural  feature  of  whole  software,  in  particular,  of  future 
programming  technologies  and  operation  systems.  ' 
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2.6  Computer  of  non  von  Neumann  axchitectiure  . 

The  same  paradigm  demands  a  fundamental  reconstruction  of  von  Neumann  computer  architecture. 

As  it  has  been  said  above  the  data-driven  (in  perspective,  event-driven)  organization  radically  changes  the 
data  processing  itself  by  making  it  decentralized  and  independent  of  number  of  processors.  It  diffuses  the  frontier 
between  the  hardware  and  software,  that  permits,  in  particular,  to  use  maximal  number  of  hardware  components 
for  supporting  all  constituents  of  the  computation  flow. 

That  qualitatively  transforms  ”by  vertical”  the  whole  fundament  of  IT  by  ensuring  multi-level  parallelism 
of  asynchronous  computational  process  on  all  its  layers  from  element  base  up  to  operational  system  and  data 
flows  in  communication  nets. 

Thus  we  can  see  a  perspective  of  breaking  of  "unshakable  foundation"  of  the  Information  Technologies: 
Algorithm,  the  modern  computational  mathematics,  von  Neumann  architecture,  deterministic  and  sequential 
process  are  going  away  forever  to  the  history  and  making  way  for  Model,  multi-agent  architecture  and  associative 
selforganization  of  nondeterministic  decentralized  parallel  process. 


3  New  generation  of  applications 


The  new  trends,  which  have  been  discussed  in  the  previous  section,  radically  change  the  technological  basis 
in  all  spheres  of  applications.  This  concerns  first  such  domains  as  Economy  and  Finance,  CAD,  engineer  and 
scientific  calculations,  management,  control  of  compiles  technological  processes,  flows  in  distributed  nets  and 
many  others. 


3.1  Economy  and  Finance 

The  main  natural  task  of  the  computer  economy  is  the  development  of  models,  which  adequately  describe 
connections  and  relations  of  economic  parameters.  But  today  the  use  of  calculations  demands  from  the  specialists 
to  care  in  the  first  place  about  adaptation  of  their  models  to  possibilities  of  computational  methods  rather  than 
about  their  likeness  to  the  original.  With  formation  of  new  paradigm  the  traditional  barrier  between  ’’natural” 
and  ’’virtual”  modeling  will  become  more  and  more  transparent  both  for  economy  and  finance  [6).  This  allows 
resolving  optimization,  backward,  regression  and  many  other  problems  on  real  models  with  real  —  subdefinite  — 
parameters,  which  allow  incomparably  higher  quality  of  tactic  and  strategic  solutions. 


3.2  Scheduling  and  resource  planning 

The  N-models  also  ensure  a  qualitative  jump  in  that  sector  of  applications,  which  play  a  key  role  in  automati¬ 
zation  of  management  functions.  Now  the  schedule  ceases  to  be  rigid  and  determined  but  turns  into  a  corridor 
which  permits  maneuvering  with  resource  and  temporal  parameters  in  process  of  plan  implementation.  The 
resource  and  temporal  parameters  participate  as  equal  in  a  unique  computational  model,  which  makes  creation 
and  optimization  of  the  plan  much  more  natural,  simple  and  efficient.  Obviously,  changing  the  temporal  scale 
(hours,  minutes,  seconds,...)  it  is  possible  to  adapt  this  apparatus  to  control  of  complex  industrial  objects  and 
processes,  personal  activity  scheduling,  and  other  fields  of  applications. 


3.3  Active  object-oriented  DBMS 

The  transition  from  relational  to  object-oriented  DBMS  is  moving  substantially  slower  in  correspondence  to 
the  prognosis  of  the  beginning  of  90s.  This  delay  is  related  with  inertia  of  evolution  of  the  large  DB  as  well  as 
with  difficulties  of  development  of  the  object-oriented  approach  itself  in  symbiosis  with  traditional  imperative 
programming.  The  adaptation  of  the  data-driven  technology  will  allow  transforming  the  modern  relational 
DBMS  into  an  intelligent  active  object-oriented  System  of  the  next  generation.  Its  powerful  virtual  processor 
will  ensure  the  user  a  wide  spectrum  of  novel  possibilities  of  interaction  with  complex  data  integrating  hundreds 
of  tables  and  thousands  of  autonomous  functions  which  realize  computations  and  control  of  consistency  of  the 
information,  ability  to  use  of  incomplete  and  imprecise  data,  etc. 
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3.4  CAD  and  CAO 

For  these  sectors  of  applied  systems  the  transition  from  Algorithm  to  Model  radically  changes  scale  and  quality 
of  the  problem  solution  process.  By  creating  a  model  of  object  its  designer  obtains  an  ability  to  solve  any 
computational  problem  related  to  construction  of  products  of  the  corresponding  type.  No  less  principally  the 
new  IT  paradigm  will  transform  functions  of  the  complex  enterprise  management.  This  is  related  not  only  with 
the  qualitative  progress  of  its  main  constituents  —  CAD,  DBMS,  scheduling,  finance  planning,  but  also  with 
all  advantages  of  novel  decentralized  architecture. 


3.5  Natural  Language  and  Voice 

This  sector  has  no  direct  relation  to  those  components  of  new  stage  of  IT  development,  which  were  discussed 
above.  But  it  closely  concerns  the  nearest  perspective  of  IT  because  the  Natural  Language  is  the  principal  form 
of  information  practically  within  all  spheres  of  activity. 

Almost  for  thirty  years  the  problem  of  computer  NL-text  understanding  was  at  a  deadlock  but  during  the  last 
decade  radical  changes  have  taken  place  here  as  well:  the  problem  of  NL  fronf-end  for  data  bases  is  practically 
solved  on  the  basis  of  semantically-oriented  approach  [7]  which  has  begun  to 'prove  its  ability  to  solve  also  the 
problem  of  the  automatic  understanding  NL-texts  within  a  restricted  object  domains. 

Simultaneously  the  voice  recognition  technology  is  becoming  usable  to  more  and  more  wide  spectrum  of 
applications.  But  in  the  meantime  these  technics  are  oriented  to  purely  ’’phonetic”  approach  which  repeats  a 
mistake  similar  to  ’’syntactical”  methods  of  the  text  analysis.  Only  complex  integration  of  the  phonetic  recogni¬ 
tion  and  meaning-oriented  text  analysis  can  solve  the  problem  of  mass  user-computer  NL-interface  forever:  the 
text  understanding  will  allow  arising  many  times  a  quality  of  the  voice  recognition  means  and  the  transition 
from  printed  text  level  to  spoken  language  will  make  the  natural  language  communication  with  computer  really 
natural  [8]. 

The  applications  we  have  discussed  in  this  section  allow  estimating  the  scale  of  global  radical  transformation 
of  the  IT  in  the  nearest  perspective.  This  estimation  will  be  much  more  complete  if  we  add  to  this  brief  survey 
other  important  applied  directions,  such  as  intellectualization  of  Internet  and  communication,  GIS,  powerful 
heterogeneous  expert  systems,  datamining,  virtual  reality,  dynamic  models,  and  many  other  domains. 

I  hope  that  in  this  brief  survey  I  have  managed  to  represent  a  general  outline  of  the  perspective  of  the  twenty 
first  century  IT  which  will  be  qualitatively  new  by  all  its  basic  conceptions  and  at  the  same  time  completely 
real  and  close  by  the  dates  of  its  carrying  out  into  the  life. 

Now  the  crucial  question  is  clear:  either  we  will  be  able  to  organize  this  coming  revolution  as  well  designed, 
strategically  planned  and  orderly  implemented  process  or  it  will  go  through  usual  ’’vegetative”,  blind  and  slower 
evolution  leading  to  far  from  optimal  edifice  of  the  new  IT  era. 
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Abstract.  We  consider  an  approach  to  the  development  of  a  speech  control  system  for  a  robot.  The  robot 
is  working  in  an  environment  containing  several  rooms;  it  can  perform  user  commands  and  answer  questions 
of  the  following  types:  Where  are  you?  or  What  do  you  see  in  the  room?  The  system  includes  the  following 
components:  speech  input  subsystem,  linguistic  processor  to  translate  English  commands  into  a  formal 
representation,  the  robot  (simulated  by  a  program)  and  a  speech  synthesizer  to  voice  the  robot’s  messages. 
The  speech  input  and  output  subsystems  are  based  on  standard  commercially  available  software  packages. 
The  linguistic  processor  and  robot  simulator  are  implemented  with  the  help  of  two  Original  instrumental 
systems  —  Lingua-F  and  SemP-TAO.  An  outline  of  the  Lingua- Voice  project  is  also  given. 

Introduction 


Although  the  problem  of  controlling  technical  devices  by  means  of  speech  is  not  new,  it  is  still  important.  It 
has  become  of  particular  importance  recently,  as  speech  recognition  systems  have  become  available. 

Modern  projects  have  demonstrated  a  trend  to  use  natural  language  (NL)  in  all  aspects  of  interaction  with 
the  robot.  At  the  specification  stage,  NL  is  used  to  state  instructions  to  the  robot  or  a  qualitative  description 
of  the  desired  situation,  while  during  execution  of  a  command  the  robot  produces  detailed  messages  about  its 
current  actions.  As  stated  in  [1],  the  main  advantage  of  using  the  natural  language  for  robot  control  is  its  ability 
to  express  information  with  varying  degree  of  detail  and  at  different  abstraction  levels,  which  is  difficult  to 
achieve  with  a  formal  language. 

One  of  the  first  programs  understanding  natural  language  was  the  famous  system  of  Winograd  [2].  Another 
well-known  system,  SHAKEY  [3],  was  a  mobile  robot  without  a  manipulator;  it  could  understand  simple  natural- 
language  commands.  The  paper  [4]  proposed  a  system  to  control  a  remote  robot  with  the  help  of  a  limited 
vocabulary  of  words  in  a  natural  language. 

The  purpose  of  project  K ANTRA  [1, 5]  is  to  create  a  system  for  speech  communication  with  an  autonomous 
mobile  robot  that  has  two  manipulators  and  is  designed  to  perform  complex  assembly  work. 

An  approach  to  the  development  of  an  NL  interface  for  a  system  controlling  a  mobile  service  robot  working 
in  a  room  was  examined  in  [6].  Another  similar  system  [7]  includes  a  well-developed  NL  interface  that  enables 
the  human  operator  to  use  NL  to  describe  scenes  (e.g.,  rooms  in  a  building,  objects  in  the  rooms,  spatial 
relationships  between  objects,  etc.)  as  well  as  commands  and  scenarios  of  robot’s  aptiohs  in  the  environment 
(e.g.,  go  to  a  room,  carry  an  object  from  one  place  to  another,  clean  the  room). 

The  Russian  Research  Institute  of  Artificial  Intelligence  (RRIAI,  Moscow-Novosibirsk)  and  the  Institute  of 
Informatics  Systems  (Novosibirsk),  together  with  the  Institute  of  Applied  Knowledge  Processing  Systems  (FAW, 
Ulm),  are  working  on  a  speech  control  system  for  an  intelligent  robot  ' 

The  robot  controlled  by  the  system  is  working  in  a  building  containing  several  rooms.  It  executes  user 
commands  expressed  in  English,  e.g..  Go  to  room  5  or  Transfer  the  computer  from  the  first  room  to  the  second 
room.  In  addition,  it  can  answer  some  questions,  e.g..  Where  are  you?  or  What  is  located  in  the  room? 

This  paper  presents  the  architecture  and  scheme  of  operation  of  a  system  for  speech  control  of  an  intelligent 
robot.  Vfe  give  a  detailed  description  of  the  world  in  which  the  robot  is  working,  the  robot’s  abilities  and  the 
control  language.  Implementation  characteristics  of  the  main  components  of  the  system  are  presented;  the  paper 
contains  numerous  examples. 


1  Architecture  and  Operation  of  the  System 

The  problem  of  robot  control  with  spoken  natural-language  commands  is  divided  into  the  following  subtasks: 
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-  speech  recognition; 

-  translation  of  command  text  into  a  formal  representation; 

-  execution  of  the  command  and  the  corresponding  modification  of  the  robot’s  world; 

-  visualization  of  command  execution  results;  > 

-  generation  of  the  robot’s  response  and  its  transformation  into  a  voice  message. 

It  is  important  also  to  ensure  a  closed  loop  in  the  operation  of  the  speech  control  system:  reception  of  a 
command,  its  analysis,  execution,  and  return  to  the  reception  of  the  next  command. 

To  perform  these  functions,  the  system  includes  the  following  components: 

-  a  speech  entry  subsystem  containing  a  microphone,  a  sound  card,  and  a  software  speech  recognizer; 

-  a  linguistic  processor  that  receives  the  text  of  command  in  a  natural  language  (English)  from  the  speech 

recognizer  and  translates  it  into  a  formal  representation; 

-  a  command  execution  subsystem  (the  robot  simulator); 

-  a  speech  synthesizer  that  voices  the  robot’s  messages. 

The  speech  entry  subsystem  is  based  on  a  commercially  available  package,  ViaVoice  by  IBM,  which  produced 
quite  satisfactory  results  after  some  necessary  adjustment.  Speech  synthesis  uses  a  standard  software  component, 
Microsoft  Concatenated  Text-to-speech  Engine. 

The  linguistic  processor  is  constructed  with  the  Lingua-F  [8]  instrumental  system  that  uses  a  semantics- 
oriented  approach  to  the  analysis  of-NL  texts  that  was  proposed  by  A.  S.  Narin’yani  [9].  , 

The  subsystem  of  command  execution  and  the  environment  emulating  the  robot’s  world  were  implemented 
with  the  help  of  SemP-TAO  [10].  SemP-TAO  is  an  integrated  software  environment  for  knowledge  representation 
and  processing  that  was  developed  for  the  construction  of  intelligent  systems  requiring  description  of  subject 
domains  with  complex  structure  and  semantics,  as  well  as  a  combination  of  logical  inference  and  calculations 
over  imprecise  values. 

The  functional  overview  of  the  system  in  Fig.  1  demonstrates  the  complete  cycle  of  execution  of  a  command 
given  to  the  robot. 

A  command  pronounced  by  the  operator  is  transmitted  to  the  voice  recognition  system  that  transforms  a 
phonetic  representation  into  the  textual  sentence.  Then,  this  text  is  processed  by  a  linguistic  processor  that 
translates  the  sentence  into  certain  sequence  of  formal  commands.  For  interpretation,  formal  commands  are 
transported  to  the  simulator  -  a  subsystem  which  simulates  the  robot’s  behavior.  According  to  the  commands, 
the  simulator  performs  all  prescribed  actions  which  generally  results  in  a  transformation  of  the  simulated 
environment  -  the  world  of  robot.  Such  transformations  are  visualized  on  the  screen  of  computer  by  special 
program  that  enables  an  operator  to  check  robot  actions  and  states  of  its  environment.  If  a  command  assumes 
certain  explicit  answer,  then  a  subsystem  of  command  interpretation  generates  an  appropriate  text;  this  text  is 
then  transformed  into  speech  form  and  is  pronounced. 

When  processing  of  a  command  is  completed,  the  operator  can  input  the  next  command. 

2  Intelligent  robot  and  its  control  language 

In  this  section  we  consider  the  robot’s  world,  the  robot’s  features  and  abilities  as  well  as  the  robot  control 
language. 

2.1  Robot’s  world  and  robot’s  abilities 

The  robot’s  world  consists  of  several  rooms  which  may  contain  some  objects.  The  classes  of  objects  such  as 
furniture  and  equipment  are  distinguished. 

Relations  are  used  to  define  position  of  objects  with  respect  to  each  other.  Examples  of  such  relations  are: 
to  the  left,  to  the  right,  below,  above,  inside,  at  the  center,  etc. 

In  this  model  of  the  world  the  robot  is  both  an  object  and  a  subject.  As  an  object,  it  has  the  properties  of 
equipment.  As  a  subject,  it  should  be  able  to  move  furniture  and  equipment  from  one  room  to  another  and  to 
answer  questions  of  the  following  types:  Where  are  you?  What  do  you  see  there?  Is  there  a  table?. 

Therefore,  the  main  functions  performed  by  the  robot  are  following:  find,  take,  put,  move,  go,  etc. 

These  functions  correspond  to  a  set  of  operators.  The  set  of  operators  is  divided  into  two  levels.  The  first 
level  is  constituted  by  the  operators  accessible  to  the  user.  These  are  used  to  state  the  instructions  for  the  robot. 
The  second  level  is  constituted  by  the  operators  that  are  used  to  implement  operators  of  the  first  level. 
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Fig.  1.  The  functional  overview  of  the  system 
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The  first-level  operators  are  Bring,  Take  away,  Move,  Go  To,  Where  Is,  What  Is  In.  The  second-level 
operators  consists  of  the  following  operators:  Find,  Take,  Free,  Put,  Say. 

There  is  a  separate  operator  scheme  for  each  operator;  it  determines  the  conditions,  the  order  (plan)  and 
the  results  of  execution  of  the  operator.  In  contrast  to  the  systems  STRIPS  and  ABSTRIPS  [11, 12]  that  use 
linear  operator  schemes,  in  our  system  recursive  operator  schemes  are  utilized. 

For  example,  the  following  scheme  corresponds  to  the  second-level  operator  Find: 

Find  ($this)  { 

if  locations  of  $this  and  the  robot  are  identical,  then 
save  current  location  of  the  robot  in  variable  $location; 
return  $location  as  a  result; 
else 

mark  current  room  as  already  examined; 

if  the  next  room  has  not  been  examined  yet,  then 

save  location  of  the  next  room  in  variable  $new_location; 

Go  to  ($new_location) ; 

Find  ($this) ;  ' 

else 

Say  ($this,  "not  found"); 

} 


Now  we  describe  the  scheme  for  the  first-level  operator  Bring: 
Bring  ($this){ 

save  current  location  of  the  robot  in  variable  $here; 
$location:=Find  ($this) ; 

Move  ($this,  $location,  $here) ; 

} 


2.2  Formal  language  for  robot  control 

Formal  language  for  robot  control  is  developed  on  the  base  of  the  operator  schemes  described  above.  It  was 
called  FOROL  (the  FOrmal  RObot  Language) . 

This  language  includes  the  operators  Wherels,  GO,  and  MOVE.  Arguments  of  these  operators  may  be  objects 
and  rooms. 

The  description  of  an  object  has  the  following  form: 

OBJECT(name:  name-of-object,  color:  color-of .object), 
here  name.of-object  is  the  name  of  the  object,  and  color.of-object  is  the  color  (may  be  not  given). 

The  description  of  a  room  in  FOROL  has  the  following  form:  , 

ROOM  (number:  number. of  .room), 

here  number.of.room  is  an  integer  which  denotes  the  number  of  room. 

We  now  give  a  description  of  the  syntax  and  semantics  of  the  operators  of  the  language. 

The  operators  Wherels  has  the  following  form: 

Whereisfwhat:  object,  where:  room). 

Here  object  is  the  description  of  an  object  whose  location  must  be  determined  or  confirmed,  and  room  describes 
a  room. 

Note  that  one  or  both  arguments  in  the  operator  Wherels  can  be  omitted.  The  semantics  of  the  operator 
Wherels  depends  on  which  arguments  are  given,  and  which  are  omitted.  Consider  each  case  separately. 

If  only  first  argument  is  given,  then  execution  of  the  operator  results  in  searching  for  an  object  with  given 
characteristics  and  issuing  a  written  or  spoken  message  on  its  location.  If  several  objects  satisfy  the  description, 
then  the  information  on  the  first  object  is  output.  In  case  of  failure,  the  corresponding  message  is  issued. 

If  only  second  argument  is  given,  then  the  characteristics  of  all  objects  found  in  room  are  output. 

If  both  parameters  are  omitted,  then  the  characteristics  of  all  objects  found  in  the  current  room  are  output. 
The  operators  GO  has  the  following  form: 

GO  (to:  room), 

here  room  describes  a  room  to  which  the  robot  should  go. 

In  according  to  this  operator  the  robot  must  go  to  the  specified  room.  If  this  is  impossible,  the  corresponding 
niessage  is  output. 
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The  operators  MOVE  has  the  following  form; 

MOVE(  what:  thing,  from:  rooml,  to:  room2) 

Here  thing  is  the  description  of  the  object  that  should  be  moved  from  rooml  to  room2.  The  values  of  the 
char^teristics  of  the  object  are  identical  to  those  in  the  operator  Wherels,  with  the  exception  that  Robot 
should  not  be  used  for  the  name  of  the  object. 

We  note  that  only  the  first  argument  of  the  operator  MOVE  is  required  always.  All  the  other  arguments  are 
optional.  The  semantics  of  the  operator  MOVE  as  well  as  Wherels  depends  on  which  arguments  are  given. 

So,  if  all  of  three  arguments  are  given,  then  the  object  thing  must  be  moved  from  rooml  to  room2. 

If  only  two  arguments  w/iat  and  from  are  given,  then  the  object  thing  should  be  moved  from  rooml  to  the 
room  where  the  robot  is.  ; 

If  two  arguments  what  and  to  are  given,  then  thing  should  be  found  and  moved  to  room2. 

Finally,  if  only  argument  what  is  given,  then  the  object  thing  should  be  found  and  moved  to  the  room  where 
the  robot  is  situated. 

In  all  versions  of  MOVE,  a  suitable  message  is  issued  in  the  case  of  failure.  For  example:  Green  chair  is  not 
found,  Room  200  does  not  exist,  Computer  is  already  in  room  5,  etc. 

Note  that  the  FOROL  language  includes  a  small  set  of  operators,  but  due  to  a  greit  power  of  the  operators, 
this  set  suffices  to  describe  all  the  tasks  which  should  be  performed  by  the  robot.  i 


3  Linguistic  Processor 

The  linguistic  processor  (LP)  was  constructed  with  the  help  of  a  current  modification  of  the  Lingua-F  software 
environment  that  was  developed  in  the  80s  [8].  Lingua-F  supports  construction  of  an  LP  that  translates  the 
text  of  an  NL  communication  into  a  formal  representation  using  the  FOROL  language.  Lingua-F  supports  all 
stages  of  LP  construction: 

-  forming  a  vocabulary; 

-  writing  production  rules  for  lexical  and  base  analysis  of  the  input  text  and  rules  for  generation  of  the  output 
representation; 

-  compilation  of  the  rules  and  the  vocabulary; 

-  debugging  and  testing  of  the  linguistic  processor  on  a  comprehensive  data  bank  of  various  NL  messages  to 
the  robot. 

Lingua-F  has  a  facility  for  saving  a  stand-alone  LP  that  can  exist  on  its  own  and  can  be  used  in  other 
software  packages. 

The  LP  thus  constructed  is  included  in  the  speech  control  system  of  the  robot  as  a  component.  A  natural- 
language  text  is  placed  at  the  input  of  the  LP,  and  the  corresponding  formal  representation  is  generated  at 
the  input.  The  transformation  of  the  text  into  a  formal  form  is  based  on  a  semantics-oriented  approach  that 
enables  one  to  a,nalyse  the  input  text  based  on  the  semantics  and  pragmatics  of  the  subject  domain  in  which 
the  communication  with  the  robot  occurs.  ' 

The  linguistic  processor  consists  of  two  components:  the  vocabulary  containing  the  lexicon  of  NL  requests 
to  the  robot  and  the  production  component.  Consider  the  two  components  in  more  detail. 


3.1  The  vocabulary  and  types  of  NL  requests 

In  the  current  version  of  the  system  an  operator  uses  two  types  of  NL  requests  to  the  robot;  a  directive 
(command)  and  an  inquiry  (question).  At  the  semantics-oriented  approach,  the  words  that  are  included  in  the 
requests  are  subdivided  into  significant  words  which  are  reflected  in  a  formal  representation,  and  insignificant 
ones  Ignored  at  an  analysis.  ° 

We  distinguish  the  following  types  of  significant  words  used  when  addressing  to  the  robot: 

-  verbs  which  define  moving  of  objects,  e.g.,  bring,  transfer,  move-, 

-  verbs  which  initiate  movement  of  robot,  e.g.  go-, 

-  verbs  and  interrogative  words  and  collocations  which  define  search  of  an  object,  e.g.  where,  find,  search 

wtiat  room-,  >  j  j  > 

-  objects,  e.g.,  chair,  box,  table,  computer-, 

-  numerals  which  can  be  used  in  requests,  e.g.,  one,  first-, 

-  adjectives  which  define  colours,  e.g.,  red,  white,  brown,  green; 
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-  locations,  e.g.,  room; 

—  prepositions,  e.g.,  yrom,  to; 

In  addition,  requests  can  include  insignificant  words,  like:  number,  a,  an,  the,  situated. 

Using  the  above  mentioned  words  one  can  compose  directives:  Go  to  Move  something  from  ...  to  ...  and 
inquiries:  Where  or  What  room  is  located  ...,  etc.  An  order  and  a  number  of  components  of  a  request  as  well 
as  word  order  within  each  component  is  generally  not  fixed.  The  word  order  is  defined  by  a  grammar  of  the 
particular  natural  language.  The  rules  of  analysis  and  synthesis  are  constructed  so  that  to  minimise  a  feeling  of 
language  restrictions  for  an  operator. 

We  give  below  several  examples  of  NL  requests  with  corresponding  formal  irepresentations.  These  examples 
demonstrate  some  degrees  of  a  lingual  flexibility,  one  of  which  in  particular  is  a  defining  of  a  room  number. 
Having  either  digital  or  literal  spelling,  a  room  number  can  be  defined  by  both  quantitative  and  ordinal  numeral 
and,  accordingly,  located  in  a  postposition  or  preposition  to  the  word  room. 

First,  we  consider  the  directives  that  are  divided  into  types  MOVE  and  GO: 

a)  In  a  directive  of  the  type  MOVE:  transfer  the  blue  armchair  from  the^  first  room  to  room  number  4!  a 
transposition  of  the  locative  components  is  admitted:  ...  to  room  number  4  from  the  first  room.  In  addition,  a 
similar  command  will  be  analysed  correctly  when  formulated  with  an  ellipsis: '  Transfer  the  blue  armchair  from 
the  first  room  to  4-'  In  all  cases  the  directive  will  be  translated  into: 

MOVE(what:  THING(name:  armchair,  color:  blue), 
from:  ROOM(number:  1),  to:  ROOM(number:  4))\ 

b)  A  directive  like  Go  to  the  second  room!  has  completely  transparent  translation: 

GO(to:  ROOM(number:  £)). 

The  system  distinguishes  questions  that  meet  the  user  informational  needs  of  both  the  location  of  various 
objects  and  the  presence  of  objects  in  the  specified  place: 

a)  A  question  Where  is  the  robot?  can  also  be  formulated  as  to  a  partner  in  communication:  Where  are  you? 
Its  formal  representation  is: 

Whereisfwhat:  OBJECT(name:  robot)); 

b)  In  addition  to  a  question  on  the  robot  it  is  possible  to  ask  about  any  object  Where  is  the  red  box?  or  What 
place  is  the  red  box  located  in?  The  directive  Find  /  Search  the  red  box!  is  interpreted  as  an  indirect  question 
on  the  location  of  the  object; 

Wherels(what:  OBJECT (name:  box,  color:  red)); 

c)  Questions  on  the  presence  of  any  objects  in  the  room  where  the  robot  is  What  is  (located)  here  /  there  / 
m  t/iis  room?  are  translated  into: 

Wherels(what:  ?,  where:  ?); 

d)  Questions  intended  to  detect  any  objects  in  the  specified  place  Is  something  in  room  5?,  What  is  located 
/  situated  in  room  5?  are  formally  represented  as: 

Wherels(what:  ?,  where:  ROOM(number:  5)); 

e)  Alternative  question  Is  computer  in  the  room  number  2?  corresponds  to: 

Wherels(what:  OBJECT(name:  computer),  where:  ROOM (number:  2)).  . 


3.2  Production  Component 

The  production  component  of  the  linguistic  processor  translates  the  incoming  NL  phrase  in  several  steps:  lexical 
analysis,  base  analysis,  and  generation.  , 

The  rules  of  lexical  analysis  divide  the  entry  string  into  lexical  tokens  which,  after  accessing  the  dictionary, 
axe  replaced  by  the  corresponding  dictionary  entries.  Multiple  components  that  are  elements  of  a  composite  entry 
are  combined  into  a  single  component.  Such  a  composite  entry  often  serves  to  resolve  ambiguities.  Defining  a 
usage  context  of  a  word,  i.e.,  creating  a  composite  entry,  makes  it  possible  to  link  several  meanings  to  a  single 
word. 

For  instance,  consider  the  word  room  'm.  several  contexts:  a)  room  1  (or  the  first  room),  b)  in  what  room.  In 
the  first  case,  the  word  room  is  a  locating  component,  while  in  the  second  it  denotes  a  question  of  type  Wherels. 
Creation  of  the  composite  entry  what  room,  synonymous  with  the  word  where,  ensures  correct  parsing. 

In  the  base  analysis  stage,  the  parsing  tree  reflecting  the  predicate-actant  structure  of  the  phrase  is  con¬ 
structed.  First,  we  construct  the  second  actant,  which  is  the  object  group  consisting  of  a  noun  (the  object) 
and  an  adjective,  e.g.,  green  armchair.  Next,  we  construct  actants  of  two  types,  from  and  to,  which  are  the 
locative  components  represented  by  nouns  with  prepositions,  e.g.,  from  room  number  two.  Finally,  the  predicate 
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IS  concatemted  with  the  second  actant  (e.g,  bring  is  concatenated  with  green  armchair)  and  all  locative  groups 
if  any.  If  the  parsing  succeeds,  the  whole  phrase  is  reduced  to  a  single  component. 

fv,  generation  rules  transform  the  tree  representation  of  the  phrase  resulting  from  the  base  analysis  into 
the  output  representation  in  FOROL.  ° 


4  The  Lingua- Voice  system:  towards  a  cooperative  processor  for  spoken  laneuaffe 
understanding  &  & 

In  this  section,  we  shortly  summarize  the  presented  results  and  outline  our  next  project  related  to  a  voice 
recognition  field. 

The  speech  control  system  described  in  the  paper  has  been  fully  implemented  and  tested,  demonstratins 
stable  operation  in  a  large  number  of  tests. 

The  integrated  object-oriented  environment  SemP-TAO  enabled  us  to  represent  the  robot’s  world  in  a  natural 
manner,  specify  and  implement  an  extensible  formal  language  for  robot  control,  support  visualization  of  the 
states  of  the  world,  and  provide  a  convenient  user  interface. 

It  should  be  noted  that  the  system  is  not  just  a  prototype  version  of  the  speech  control  system  that  will  be 
connected  to  the  real  device.  The  integrated  model  of  the  robot  is  a  good  base  for  experiments  and  extensions 
directed  at  the  study  of  a  broad  range  of  knowledge  representation  and  processing  problems.  The  FOROL 
language,  for  example,  served  as  a  base  for  more  powerful  robot  control  language,  including  additional  tools  to 
work  with  spatial  relationships  and  advanced  facilities  for  description  of  rooms  and  objects.  Implementation  of 
this  lan^age  will  make  it  possible  to  work  on  the  development  of  a  robot  control  system  using  both  formal 
communication  means  and  a  richer  natural  language. 

The  system  described  in  this  paper  can  also  be  used  as  a  solid  testing  ground  for  research  of  the  use  of  a 
spoken  language  for  communication  with  a  wide  spectrum  of  applications.  In  this  respect,  it  has  given  a  rise  to 
a  new  project  called  Lingua- Voice  which  we  outline  below. 


The  idea  of  the  Lingua-Voice  project  is  to  technologically  fulfill  a  gap  between  an  output  of  a  standard  voice 
recognition  system  and  an  input  of  an  application. 

Today,  industrial  speech  processors  produce  rather  raw  output  which,  in  the  best  case,  can  include  a  simple 
post-processing  based  on  a  user-defined  context-free  grammar.  In  fact,  a  voice  recognition  system  itself  supports 
only  a  small  part  of  job  needed  to  provide  a  really  comprehensive  communication  with  applications.  In  particular, 
voice  processing  systems  presented  today  in  the  software  market  are  responsible  for  selection  (from  a  dozen  of 
phonetic  hypotheses)  of  ’’the  most  probable”  word,  taking  into  account  some  universal  phonetic  and  statistic 
data,  not  the  information  related  somehow  to  the  world  of  application  or  to  linguistics. 

We  are  certain  that  the  approach  described  in  [8]  for  automatic  text  processing  based  on  orientation  to 
a  restricted  subject  domain  and  simultaneous  processing  of  many  variants  is  especially  adequate  for  spoken 
language  (SL)  understanding. 

Our  new  project  called  Lingua- Voice  concerns  the  following  principles:  ' 


-  Multi-variant  processing, 

—  Automated  specification  and  adjustment  of  a  SL-processor  to  application, 

-  Specialized  agents  for  SL-processing, 

—  Closer  integration  of  voice  and  linguistic  processing. 


This  development  leads  us  to  a  construction  of  a  software  architecture  and  environment  which  are  shortly 
characterized  below.  Their  general  structure  is  presented  at  Fig.  2  (where  ’’Voice  recognizer”  and  ’’Linguistic 
processor”  functionally  correspond  to  similar  components  shown  at  Fig.  1). 

The  Lingua- Voice  system  is  based  on  a  version  of  the  Lingua-F  support  environment  which  has  recently 
been  implemented  by  M.Zhigalov  and  D.Shishkin. 

The  Lingua- Voice  system  starts  with  initiation  of  a  certain  voice  recognition  engine:  Via  Voice,  Dragon  or 
whatever.  After  the  engine  has  completed  its  work,  the  whole  set  of  phonetic  variants  is  ’’extracted”  from  its 
inner  memory  and  transmitted  to  further  processing  modules.  This  data  has  the  following  structure: 


w  -<wi  -  {hi,i;/ii,2;-;hi,„j > 
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Fig.  2.  General  structure  of  the  Lingua- Voice 
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where  Wi  is  a  cluster  of  words  detected  for  the  i-th  potential  word.  (This  picture  is  obviously  simplified  for 
continuous  speech.)  We  call  clusters  subdefinite  words  and  W-structures  subdefinite  phrases  to  note  a  relationship 
between  the  issues  considered  here  and  classical  works  of  A.Narin’ani  on  processing  of  non-complete  information. 

In  the  general  case,  the  purpose  of  a  concrete  Lingua/- Voice  processor  is  to  organize  the  application  of 
specidized  processing  agents  to  such  a  vector  W.  If  no  correct  variants  are  found,  the  process  is  considered  to 
be  failed,  if  a  unique  variant  is  found,  it  is  passed  over  to  the  application;  if  the  result  is  ambiguous,  then,  in 
order  to  refine  it,  a  kind  of  a  dialog  is  initiated. 


To  exemplify  these  agents,  we  mention  here 

-  statistical  corrector, 

-  syntactical  filter, 

-  semantic  filter  and 

-  multi- variant  analyzer. 

Thus,  statistical  corrector  uses  lexical  and  statistical  knowledge  entered  through  the  special  user-friendly 
environment  of  the  Lingua- Voice  system  during  an  adjustment  of  a  concrete  processor.  These  data  enables  us  to 
efficiently  rearrange  and  refine  too  universal  ’’probability  estimations”  elaborated  by  a  voice  recognition  engine; 
in  some  cases,  corrector  is  able  to  extend  the  set  of  hypotheses  by  additional  words  due  to  a  priori  defined 
contextual  statistical  associations. 

The  work  of  the  above  mentioned  components  can  be  illustrated  by  an  artificially  simplified  example  of  processing  a 
phrase:  ° 

Take  this  box  and  put  it  on  the  sixteenth  table 

The  result  of  application  of  corrector  can  be  illustrated  by  a  table  (abridged): 

Lingua- Voice  corrector  output 
eight  -  22%,  eighty  -  13%,  take  -  9%,'' ... 


can  -  10%,  an  -  10%,  am  -  10%,  Md  -  10%,  ... 


one  -  15%,  what  -  16%,  would  -  12%,  on  -  12%,  ... 
thirteen,  sixteen,  thirty,  sixty 


Pay  attention  that  the  ViaVoice  engine  has  not  detected  the  words  take,  and  and  on\  they  have  been  reconstructed 
by  the  Lingua  Voice  corrector.  ' 

For  our  example,  the  syntactical  filter  transforms  a  configuration  {this)  -f  [box,  boxes)  into  {this)  +  {6oa;}. 

Since  the  considered  domain  restricts  the  quantity  of  tables  by  twenty,  semantic  filter  refines  the  subdefinite  word 
{thirteen,  sixteen,  thirty,  sixty)  to  {thirteen,  sixteen). 

The  first  results  of  constructing  the  Lingua-Voice  system  are  rather  encouraging.  Along  with  ’’The  robot”,  we 
have  in  mind  an  application  related  to  the  Internet  communication.  Also,  the  development  of  the  Lingua- Voice 
for  the  Russian  language  is  very  important  and  challenging. 
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Abstract.  Many  different  sign  languages  are  in  use  to  communicate,  especially  among  the  hearing  im¬ 
paired  people.  Translation  of  one  sign  language  to  another  is  a  difficult  problem  that  need  efficient  solution. 
Processing  of  signs  is  different  from  the  processing  of  words  in  natural  languages.  Sign  languages  use  shapes 
and  movements  to  express  meaning.  The  objective  of  our  research  project  is  to  develop  a  multi-lingual  ma¬ 
chine  translation  system  for  sign  languages.  As  a  first  step  towards  acheiving  this  objective  we  analyzed 
three  sign  languages.  This  paper  outlines  the  current  research  results.  ’ 


1  Introduction 

Many  different  sign  languages  are  in  use  in  many  different  parts  of  the  world.  People  who  are  using  different 
sign  languages  communicate  with  the  help  of  a  translator.  People  with  no  hearing  disabilty  and  unfamilier  with 
the  sign  language  may  need  interpreters  of  sign  languages  to  communicate  with  hearing  impaired  people.  With 
the  recent  advances  in  communication  and  transportation  technologies,  there  is  an  increasing  demand  for  such 
interpreters  and  translators  for  the  disabled.  The  problem  of  translation  of  sign  languages  can  be  eliminated  by 
using  a  universally  accepted  standard  sign  language.  Developing  a  machine  translation  system  for  sign  languages 
is  another  solution.  This  paper  presents  the  results  of  the  later  approach. 

1.1  Sign  Languages 

Sign  Language  (SL)  is  one  of  the  methods  used  by  the  hearing  impaired  people  to  communicate  with  others.  SL 
is  not  unique.  The  formation  of  a  SL  is  influenced  by  the  environment,  customs,  regions  of  a  country  and  the 
natural  language  used  in  that  country.  Thus,  the  signs  can  be  different  in  from  one  SL  to  another.  Signs  express 
meaning  through  shapes  and  movements.  This  way  of  communication  is  different  from  the  words  and  sentences 
used  in  natural  languages.  It  is  observed  that  different  sign  languages  share  common  signs  between  them.  For 
example,  the  signs  for  victory  and  failure  are  the  same  in  any  SL  [1].  A  sign  can  have  a  different  meaning  in  a 
different  SL;  for  example,  the  promise  sign  in  Japan  is  the  same  as  the  friend  sign  in  Sri  Lanka. 

There  were  attempts  to  develop  a  standard  universal  sign  language  for  all.  However,  these  attempts  were 
not  successful  enough  to  develop  a  universally  accepted  or  truly  international  SL.  In  1971,  the  international 
sign  form  called  Gestuno  was  developed  by  the  World  Federation  of  the  Deaf  [2].  Its  Vocabulary  is  based  on  the 
European  SLs  and  some  European  countries  have  adopted  Gestuno.  It  is  mainly  used  at  international  meetings. 
However,  Gestuno  is  not  widely  accepted  in  the  world  for  day  to  day  use.  Translators  perform  the  much  needed 
help  to  establish  communication  between  different  SL  users  [3]. 

Until  the  1960s,  SL  was  not  considered  to  be  a  language,  and  it  was  used  only  for  educating  for  hearing 
impaired.  In  the  1980s,  the  Sign  Linguistics  was  born  and  SL  began  to  be  researched  from  a  linguistics  point  of 
view  [4]. 

The  term  signs  include  gestures  in  its  general  meaning.  When  used  in  SL  linguistics,  the  term  signs  mean 
the  components  of  SL  which  are  equivalent  to  a  word  in  a  natural  language. 

Sign  Language  (ASL),  Sri  Lankan  Sign  Language  (SSL)  and  Japanese  Sign  Language 
(JSL)  are  analyzed  in  this  paper.  Section  2  of  this  paper  discusses  the  methodology  used  to  compare  sign 
languages.  Section  3  outlines  the  implementation  and  experimental  results.  Section  4  gives  the  conclustion. 

2  Methodology 

2.1  The  basic  idea 

Analaysis  of  SLs  is  a  basic  requirement  in  developing  a  SL  machine  translation  system.  To  discover  the  rules 
for  translating  a  sign  from  one  SL  into  another  enables  the  development  of  the  translation  system.  Also,  it 
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is  necessary  to  analyze  the  relationships  between  SLs  for  developing  the  system.  Some  of  these  rules  and 
relationships  between  SLs  will  be  discussed  in  this  section. 

In  natural  language  processing,  the  basic  unit  is  a  word  in  analysis.  Similarly,  the  analysis  of  a  sign  leads  to 
the  analysis  of  a  SL.  The  structure  of  a  sign  can  be  defined  by  morpheme  and  phoneme.  These  morphological 
and  the  phonological  analysis  are  the  objects  of  mainstream  research  [4].  Following  section  focuses  on  the 
phonological  analysis. 

2.2  Phonological  analysis 

In  phonological  analysis,  the  parameters  of  a  sign  are  defined.  It  is  considered  that  four  parameters  correspond 
to  the  phoneme  of  a  sign  language  [4].  William  C.  Stokoe  introduced  composition  parameters,  DEZ  (designator), 
TAB  (tabulations)  and  SIG  (signation).  DEZ  represents  hand  shapes,  TAB  represents  locations  on  the  body 
and  SIG  represents  hand  movements.  Battison  [4]  added  the  fourth  one,  ORI  (the  orientation  of  the  palm). 
These  four  parameters  are  considered  to  be  the,  components  of  a  sign.  We  analyze  the  signs  according  to  these 
four  articulatory  parameters. 

3  Implementation  | 

3.1  Vocabulary 

Signs  common  to  all  three  SLs  are  picked  up  from  existing  books  [5]  [6]  [7],  Table  1  shows  the  total  number  of 
signs  for  the  SLs. 


Table  1.  Number  of  signs 


in  books 

selected 

1  comparable 

verbs 

nouns 

no. 

ASL 

1167 

650 

SSL 

1051 

441 

25 

81 

10 

JSL 

15293 

3941 

!  (Totablie) 

Selected  vocabulary  in  Table  1  shows  the  number  of  signs  after  eliminating  the  signs  representing  strong 
religious  meaning,  or  unique  cultural  characteristics,  country  names  and  signs  with  complex  movement.  The 
vocabulary  of  SSL  is  the  smallest  of  three,  and  it  is  picked  up  as  the  basic  SL.  Among  selected  signs,  only  116 
signs  are  comparable  among  3  SLs.  They  are  divided  into  three  categories,  verbs,  nouns  and  numbers. 


3.2  Computerizing  signs 

For  computers  to  recognize  signs,  they  must  be  coded  for  parameters.  Figure  1  shows  the  code  form,  mainly 
divided  into  two,  the  right  hand  and  the  left  hand.  The  right  hand  part  begins  from  r  and  the  left  hand  part 
begins  from  1.  Same  components  are  applied  to  both  hands. 


rieht  hanc 

eft  hand 

r 

l|2i3 

_ • _ ! _ _ 

4  is 

6 

7  8 

1 

ORI  A 

Fig.  1.  Code  Form 


As  default,  the  right  hand  is  considered  as  the  preferred  hand  and  the  fingers  are  open.  The  complete  code 
is  given  in  the  Lab.  report  [8]. 
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1.  DEZ  (Hand  shape) 

There  are  20  hand  shapes  and  8  shape  aspects.  In  Figure  1,  the  columns  1  to  3  represent  a  code  for  DEZ 
parameter.  The  first  half,  a  pair  of  1  and  2,  represents  a  hand  shape,  and  the  second  half,  3,  represents  a 
shape  aspect.  The  column  1  shows  the  number  of  standing  fingers,  and  the  column  2  represents  the  code 
identity.  For  example,  code  23  means  two  fingers  are  standing  {2)  and  belongs  to  third  hand  shape  (5)  (the 
V  shape,  the  index  and  the  middle  fingers  are  standing) . 

2.  ORI  (Orientation  of  the  palm  in  relationship  to  the  body) 

The  columns  4  and  5  represent  a  code  for  ORI  parameter.  There  are  6  orientations  of  the  palm  in  relation 
to  the  body;  up,  down,  front,  back,  inside  and  outside.  The  column  5  shows  direction  of  the  fingertips. 

3.  TAB  (Initial  location) 

The  column  6  shows  a  code  for  TAB  parameter.  Signing  space  in  relation  to  the  body  is  divided  horizontally 
into  six  positions  from  above  the  head  to  below  the  waist. 

4.  SIG  (Movement) 

The  columns  7  and  8  are  for  SIG  parameter.  In  column  7,  seven  hand  movements  are  identified,  one  static 
and  six  dynamic  movements  where  the  oblique  movements  are  also  includes.  Column  8  for  representing  11 
movement  aspects.  These  were  selected  carefully  according  to  Stokoe’s  classification  [4]. 

For  an  example,  according  to  the  above  process,  the  ASL  sign  for  read  is  coded  as  r233rr42w  1512iir50n. 


3.3  Automatic  code  generator 

The  automatic  code  generator  is  developed  on  SunOS  4.1.4.  for  efficient  data  input.  Figure  2  shows  the  basic 
screen  of  generator.  The  screen  is  divided  into  two,  information  part  and  coding  part.  At  information  part,  user 


selects  the  target  SL  firom  ASL,  SSL  or  JSL  and  inputs  a  meaning  of  sign  from  the  keyboard.  Result  of  coding 
appears  in  this  part.  At  coding  part,  14  lists  correspond  to  the  columns  of  Figure  1.  Figure  2  shows  only  the 
nght  hand  part.  A  sign  is  coded;by  clicking  twice  in  one  of  the  each  list.  This  work  makes  three  code  databases 
for  each  SL,  like 

go  ;  rl20ru55w  1120ru55w 

look  :  r233rr25n 

read  :  r233rr42w  1512ur50n 

3.4  Structured  comparison 

Using  the  database  described  in  section  3.3,  coded  signs  are  compared  for  parameters,  DEZ,  ORI,  TAB  and 
SIG  on  commonality,  similarity  and  difference  of  SLs.  In  commonality,  all  numbers  or  characters  of  a  code 
are  completely  the  same.  In  similarity,  only  the  first  half  code  is  the  same  .  In  difference  codes  are  completely 
different.  Table  2  shows  examples  in  DEZ  parameter. 

Out  of  all  116  signs  are  compared,  only  50  signs  involve  both  hands. 
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Table  2.  Examples 


Commonality 

(adopt) 

Similarity 

(bread) 

Difference 

(wear) 

ASL 

510 

512 

232 

SSL 

510 

510 

510 

JSL 

510 

515 

110 

4  Experimental  results  s 

4.1  Commonality 

Figure  3  shows  the  percentage  of  commonality  in  the  SLs.  In  the  graph  of  the  right  hand,  the  range  of  values  is 
10%  to  60%.  About  10%  of  the  signs  are  common  to  three  SLs  in  any  parameter.  DEZ,  ORI  and  SIG  parameters 
show  a  low  rate  of  commonality.  TAB  is  by  far  the  highest  about  35%.  With  respect  to  two  SLs,  in  any  SL 
combination,  its  rate  is  higher  about  5%  to  20%  than  that  of  three  SLs.  T^he  graph  of  the  left  hand  shows  a 
similar  tendency  to  the  right  hand. 


THE  LEFT  HAND 


THE  RIGHT  HAND 


Fig.  3.  Classification  rate  of  commonality 


4.2  Similarity 

Figure  4  shows  the  percentage  of  similarity  between  SLs.  Commonality  value  also  a  subset  of  similarity.  In  the 
right  hand,  12%  of  the  signs  are  judged  to  be  similar,  in  all  three  SLs,  in  all  parameters.  DEZ  rate  is  high  as 
well  as  TAB,  except  between  SSL  and  JSL.  However,  the  rate  of  commonality  between  thern  is  high.  DEZ  and 
ORI  rates  increase  20%  compared  to  the  rate  of  commonality,  while  TAB  and  SIG  rates  increase  only  about 
5%.  The  rate  of  SIG  is  the  lowest,  and  it  is  a  little  different  from  the  commonality  rate. 

The  left  hand  is  almost  the  same  as  the  right  hand,  but  in  the  SIG  parameter,  the  value  shows  high 
comparatively. 


4.3  Consideration 

For  the  DEZ  parameter,  there  is  a  55%  of  similarity  between  ASL  and  JSL,  so  it  can  be  applied  to  a  SL 
translation  system  that  the  hand  shapes  of  sign  are  the  same  between  these  two  SLs. 
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parameter 


THE  RIGHT  HAND 


parameter 


Fig.  4.  Classification  rate  of  similarity 


The  commonaJ^ity  and  similarity  of  the  ORI  parameter  indicates  a  low  rate  in  any  graph,  so  an  applicable 
rule  and  relationships  cannot  be  found.  j  6  f  ,  su  an  appucaoie 

All  show  that  the  commonality  of  the  TAB  parameter  has  a  high  rate.  In  any  SL,  70%  of  signs  are 

^thSoo^tiorall^  unconsciously  in  front  of  chest  and  visibility!  high 

m  tins  position  allows  receivers  to  recognize  signs  clearly.  Since  the  70%  of  TAB  parameters  is  all  the  same  from 

f ^  parameter.  When  a  sign  translates  to  another  SL  using 

t'^J^slatmn  system,  the  location  in  relation  to  the  body  will  not  be  changed  at  a  high  rate.  ® 

rulefcaLot  b^S'’  but  other  graphs  show  low  value  and 


4.4  The  verb  category 

The  above  analys^  applied  to  all  the  signs.  Now,  the  analysis  turns  to  a  comparison  by  parts  of  speech  and  the 
fou  par^eters.  One  hundred  and  sixteen  signs  are  classified  into  three  cate^es,  verbs,  n^nsTd  numbers 
Only  verbs  are  considered  here.  The  verb  category  has  25  signs  out  of  which  18  signs  use  the  boThanr^ 
simfiip'r  ^  comparison  of  verbs  by  the  four  parameters.  It  is  simUar  to  the  results  for 

LThaTXhs  the  others.  The  reason  for  this  resL 

de^^n^nn  f  movement  m  natural  language  and  their  concepts  are  almost  the  same  in  any  language  The 
escription  of  a  sign  for  verb  also  has  a  similar  concept  and  this  is  reflected  in  the  similarity  of  SIG  parLeter. 

5  Conclusions  * 

The  relationships  between  SLs  are  found  by  comparing  SLs  according  to  parameters  and  categories  40%  of 
SVrSlaLnTre  '''  three  SLs.  60%  of  hand  shapes  are  similar  in  ASL  and  JSL 

reSar^rbrntn  ti  K  ^  ^be  hand  movement  also  needs  further 

research  but  m  the  verb  category,  25%  are  similar  in  the  three  SLs.  Analysis  of  the  verb  category  proves  that 

more  rules  can  be  found  in  the  specified  categories.  It  is  effective  to  find  the  rules  and  relationships  between 
SLs  by  category.  Classifying  categories  correctly,  and  comparing  categories  is  meaningful. 

•  r  special  relationship  .or  similarity  between  any  pair  of  SLs  among  3  SLs  investigated  Tbic, 

Lay  "o.'"”  ““-J-  -“ure  and,  so  a  Lgh  rate  of 
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u 

parameter 


is  «  THE  RIGHT  HAND 


I  parameter 


Fig.  5.  Classification  rate  of  similarity  in  the  verb  category 
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Abstract  We  show  how  the  synchronous  programming  language  Esterel  can  be  extended  by  a  new  statement  to  im¬ 
plement  mutual  exclusive  sections.  We  also  show  how  the  thereby  extended  Esterel  language  can  be  translated  back  to 
standard  Esterel  and  we  prove  the  correctness  of  this  transformation.  Additionally,  we  show  that  the  translation  fits  well 
into  different  verification  approaches. 


1  Introduction 

Synchronous  languages  like  Esterel  [1,3]  allow  to  describe  multithreaded  systems  where  the  threads  run  in  a  synchronous 
manner.  The  synchronization  of  threads  is  for  free  since  it  is  achieved  directly  by  the  semantics  of  the  language:  Most  of 
&e  statements  of  symchronous  languages  do  not  consume  time.  Instead,  consumption  of  time  must  be  explicitely  enforced 
by  special  statements,  as  e.g.  the  pause  statement  of  Esterel.  As  it  is  only  possible  to  consume  a  multiple  of  a  logical  unit 
of  time,  all  threads  of  a  system  run  synchronously  to  each  other*. 

There  exists  techniques  to  translate  a  multithreaded  Esterel  program  into  a  single-threaded  program  [2]  such  that  it 
can  be  translated  into  standard  sequential  programming  languages  as  C.  Therefore,  Esterel  designs  can  be  conveniently 
translated  to  software  parts  of  embedded  systems.  Moreover,  there  are  techniques  to  directly  map  Esterel  designs  to 
register-transfer  circuits  [2],  It  has  been  shown  that  the  results  of  this  hardware  synthesis  are  almost  optimal  [8,9]  such 
that  additional  optimizations  are  usually  not  necessary.  For  this  reason,  Esterel  can  also  be  used  as  a  good  basis  for 
hardware  synthesis. 

To  summarize,  Esterel  can  be  used  as  basis  for  hardware-software  codesign  where  Esterel  allows  to  describe  the 
system  mdependent  of  the  later  realization  in  hardware  or  software.  Hence,  Esterel  is  a  good  language  for  designing  the 
digital  part  of  embedded  systems.  However,  from  the  viewpoint  of  software  engineers,  the  communication  mechanisms 
prodded  by  Esterel  are  rather  poor:  the  only  way  for  threads  to  communicate  with  each  other  is  to  broadcast  globally 
visible  signals.  Instead,  software  engineers  are  often  used  to  implement  communication  via  shared  memory.  Clearly,  this 
presupposes  that  we  have  critical  sections  of  code  that  are  executed  in  a  mutually  exclusive  manner. 

It  IS  not  surpnsmg  that  a  lot  of  different  communication  principles  can  be  implemented  with  the  basic  broadcasting 
prmciple  provided  by  Esterel.  In  particular,  the  communication  over  shared  variables  is,  of  course,  possible.  The  problem 
IS,  however,  that  the  mutual  access  to  these  variables  must  be  guaranteed  by  the  programmer,  since  there  are  no  semaphore 
constructs  m  Esterel.  Nevertheless,  these  can  be  implemented  in  Esterel,  but  we  feel  that  especially  the  imitation  of  mutual 
exclusion  is  an  error  prone  task. 

The  critical  section  problem  was  first  formulated  by  Dijkstra  [4]:  One  considers  n  (n  >  2)  processes  that  communicate 
with  each  other  through  shared  variables.  Each  process  has  a  critical  code  section  and  a  noncritical  code  section.  The 

I  3**'^  financed  by  the  DFG  priority  program  ‘Design  and  Design  Methodology  of  Embedded  Systems’. 

no°t  bi'e  J1d5*f  between  different  synchronization  points  of  time  may  differ,  i.e.  the  synchronization  points  need 
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solution  of  the  ‘critical  section  problem’  must  satisfy  the  mutual  exclusion  property,  avoid  simultaneous  execution  of 
critical  sections  in  two  or  more  processes.  In  addition,  the  following  fairness  condition  must  be  satisfied:  each  critical 
section  that  can  be  executed  will  not  be  ignored  infinitely  many  times.  We  say  a  solution  of  the  ‘critical  section  problem’ 
is  safe  iff  it  fulfills  the  mutual  exclusion  property,  and  it  is  called  to  be  fair  iff  it  fulfills  the  fairness  property. 

In  1968,  Dijkstra  described  [5]  a  safe  and  fair  solution  for  two  processes.  Lamport  [6]  presented  in  1974  the  correct 
solution  for  n  processes,  called  the  bakery’  algorithm.  This  algorithm  uses  unbounded  counters,  and  can  therefore  not  be 
implemented  by  a  finite  state  machine.  The  first  finite  state  solution  for  n  processes  was  described  by  Peterson  [7]  in  1983. 
In  principle,  we  could  choose  Peterson’s  algorithm  for  the  solution  of  our  problem. 

We  preferred  however  another  solution  since  this  allowed  us  to  separate  the  mutual  exclusion  problem  from  the 
remaining  program  statements:  To  implement  the  mutual  exclusion,  we  introduce  an  explicit  arbitration  process  that 
schedules  the  different  critical  sections  that  could  be  executed  next.  It  is  important  that  the  arbitration  is  safe,  i.e.  at 
each  point  of  time,  at  most  one  process  is  granted  access  to  the  critical  section,  and  fair.  As  it  is  not  straightforward  to 
implement  such  an  arbitration  process,  we  have  extended  the  Esterel  language  by  a  new  region  statement  for  establishing 
critical  sections. 

To  implement  the  arbitration  process,  we  use  a  modification  of  the  DMA  arbitration  controller  given  by  Dill  [10].  This 
modification  is  finite  state:  For  n  processes,  we  obtain  4n  +  2  boolean  valued  signals,  where  only  2n  of  these  signals 
are  state  variables.  The  state  number  grows  proportional  to  C)(n2”),  but  what  is, more  important:  The  representation 
by  OBDDs  for  symbolic  model  checking  is  polynomial  [10],  so  that  this  implementation  lends  itself  well  for  verifying 
such  programs  by  symbolic  model  checking.  We  show  in  this  paper  how  programs  with  the  new  region  statement  can  be 
translated  to  standard  Esterel  programs  and  we  prove  the  correctness  of  this  translation.  The  translation  involves  mainly 
the  parallel  execution  of  a  fair  arbitration  process  and  interfacing  the  critical  sections  with  a  simple  protocol.  It  is  our 
aim  to  develop  a  translation  that  leads  to  a  simple  verification  afterwards.  In  terms  of  model  checking,  this  means  that  the 
arbitration  process  should  have  a  good  BDD  representation.  Hence,  we  do  not  work  with  queues  or  other  higher  order 
data  types  here. 

The  paper  is  organized  as  follows:  in  the  next  section,  we  present  the  syntax  and  meaning  of  our  new  statement  for 
establishing  critical  sections.  We  also  present  the  basics  of  the  translation  of  these  programs  back  to  standard  Esterel. 
After  that,  we  prove  the  correctness  of  the  translation.  This  is  done  twofold:  oh  the  one  hand,  we  prove  the  correctness  by 
means  of  model  checking  techniques.  This  shows  that  our  arbitration  process  has  a  good  BDD  representation  such  that 
Esterel  programs  with  critical  sections  can  be  directly  verified  by  model  checking  techniques.  On  the  other  hand,  we  prove 
the  correctness  by  a  paper-and-pencil  proof  that  leads  to  an  interactive  proof  rule  that  can  be  used  to  eliminate  critical 
sections  for  proving  a  given  specification. 

2  Extending  Esterel  by  Mutual  Exclusion 

To  express  mutual  exclusion,  we  extend  the  Esterel  language  by  a  region  statement  designed  for  declaring  critical  program 
sections  that  can  only  be  executed  exclusively  from  each  other.  The  syntax  of  the  region  stateirient  is  as  follows,  where 
ident  is  a  name  and  statement  is  an  arbitrary  (extended)  Esterel  statement: 

region  ident  stotemewt  end  region 

We  say  that  the  region  statement  region  A  S  end  region  belongs  to  the  region  A  and  consists  of  the  body  S.  A  program 
can  contain  many  region  statements  belonging  to  the  same  region.  The  meaning  of  the  statement  is  as  follows:  If  some 
region  statements  region  A  Si  end  region  for  i  =  1, . . . ,  A:  are  to  be  executed  in  parallel,  only  one  body  Sj  of  the  region 
statements  is  chosen  for  execution  while  the  remaining  statements  have  to  wait.  The  body  Sj  of  this  selected  region 
statement  is  then  executed,  while  all  other  region  statements  are  suspended  imtil  the  execution  of  Sj  terminates.  After 
termination  of  Sj  a  new  choice  among  the  remaining  region  statements  is  made  and  so  on.^  Hence,  at  each  point  of  time, 
at  most  one  body  Sj,l  <  j  <  nofs.  region  statement  belonging  to  the  region  A  can  be  active  (mutual  exclusion).  Note 
that  execution  of  the  body  Sj  of  the  selected  region  statement  starts  at  the  same  point  of  time  where  the  region  statement 
is  executed,  i.e.,  entering  the  region  statement  does  not  consume  time. 

It  is  important  to  require  additionally  that  the  access  to  the  region  A  is  fair,  i.e.  if  a  region  statement  region  A  Sj 
end  region  is  started,  then  we  guarantee  that  its  body  Sj  will  be  executed  after  some  time.  In  other  words,  we  avoid  that 
one  of  the  region  statements  must  wait  forever  and  is  never  granted  to  execute  its  body.  Clearly,  to  assure  this,  we  must 
assume  that  all  bodies  Sj  of  the  region  statements  terminate  in  each  case.  For  example,  suppose  we  have  k  stores  storeu 
for  i  =  1, . . . ,  A:,  three  modules  Produceu  Consumei,  and  Duplicatei  for  alH  =  1, . . . ,  A:,  and  wish  to  implement  the 


^  To  avoid  obvious  deadlocks,  we  forbid  nested  region  statements  that  belong  to  the  same  region. 
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To  this  end.  we  eao  use  uow  the  foUowtog  region  statements 

With  identifiers  Ai, Ak  and  run  them  m  parallel: 


-  region  Ai  Producci  end  region 

-  region  Ai  Consumei  end  region 

-  region  Ai  Duplicatei  end  region 


Although  Esterel  does  not  provide  statements  for  mutual  exclusive  execution  of  threads  directly,  the  Esterel  statements 
are  powerfol  enough  to  implement  such  a  behavior.  To  see  this,  we  show  now  how  our  region  statements  can  be  translated 
to  standard  Esterel:  Let  i?i-region  A  Si  end  region  for  i  =  1, . . . ,  n  are  all  the  region  statements  belonging  to  the  region 
A  m  an  extended  Esterel  program  S(Ri,. . . ,  il„).  Then,  we  replace  5(dRi , . . . ,  sR„)  by  the  following  statement: 


r  trap  trm  in 

signal  f A, ai,..., an  in 

S{Pi P„);  exit  trm 

arbitrate  A  (ffi Pn,  /yi, a„) 

end  signal 
end  trap 


where  Pi  = 


weak  abort 
sustain  Qi 

when  immediate  a,; 

Si', 

emit /a 


The  statement  exit  trm  is  used  to  Idave  the  external  trap  statement  in  case  when  S  terminates.  The  statement  Pi  behaves 
as  follows:  Firstly,  the  wish  of  ‘region  A  Si  end  region’  to  access  the  critical  region  A  is  signaled  by  emitting  the  request 

si^l  0i.  The  additional  Esterel  thread  arbitrateA{gi, . . . ,  /a,  ai . a„)  collects  all  these  requests  and  decides 

which  one  of  the  region  statements  is  allowed  to  enter  the  critical  section.  This  decision  is  broadcasted  via  the  signal  ai 
which  allows  the  statement  Ri  to  enter  the  critical  section.  After  that.  Si  is  executed  and  no  further  grants  are  given  by 
the  ^bitotion  thread  before  Si  terminates.  The  termination  of  Si  is  signaled  by  emitting  the  release  signal  /a  of  region 
A  which  mdicates  that  Ri  leaves  the  region  A.  This  instructs  the  arbitration  thread  to  make  new  choices  and  emit  new 
access  signals  aj. 

The  arbitration  thread  can  immediately  select  one  of  the  regions  and  hence,  the  emission  of  gi  can  be  immediately 
aborted  m  P^.  The  abortion  is  however  weak  which  means  that  even  if  P  is  immediately  selected,  there  wiU  be  an  emission 
of  for  at  least  one  point  of  time.  Note  further  that  the  request  signal  gi  is  emitted  as  long  as  P  is  not  allowed  to  enter 
Its  critical  section  5i. 

TTie  above  replacement  of  the  region  statements  by  standard  Esterel  statements  is  straightforward  and  the  code  size 
remams  more  or  less  the  same.  However,  the  correctness  of  the  replacement  is  based  on  a  correct  Esterel  implementation 
of  die  arbitration  process.  Hence,  the  correctness  of  the  translation  depends  clearly  on  a  sound  implementation  of  the 
arbitration  process  that  is  given  in  the  next  section. 


3  Esterel  Implementation  of  the  Arbitration  Process 

In  this  section,  we  present  a  possible  implementation  of  the  arbitration  process  that  can  be  used  for  a  translation  of 
our  extended  Esterel  language  back  to  standard  Esterel.  The  basic  idea  of  this  arbitration  process  goes  back  to  a  DMA 
controller  given  by  David  Dill  [10]!  However,  the  circuit  given  by  Dill  makes  arbitration  decisions  at  any  point  of  time 
smce  it  assiraes  that  a  smgle  unit  of  time  is  sufficient  for  accessing  the  shared  resource.  However,  this  does  not  hold  in 

our  case  and  therefore,  we  need  to  adapt  the  arbitration. 

Now,  what  does  the  arbitration  process  have  to  do?  It  has  to  choose  one  of  all  requesting  threads  ,  i.  e.  among  the  indices 
where  die  correspondmg  request  signal  gi  is  present  at  the  current  instant.  The  decision  is  then  signaled  via  emitting 
a  grant  sipid  ai.  After  getting  access,  the  region  section  i  executes  its  critical  section,  and  hence  the  arbitration  thread 

must  await  the  termmation  of  Si  (signaled  by  /a).  The  next  arbitration  decision  can  be  made  when  the  release  signal  fA 
is  emitted  by  Pj.  a 

The  Esterel  implementation  of  the  arbitration  process  for  a  region  A  with  n  region  statements  is  given  in  Figure  1. 
there  we  n  mputs  pi, . . .,  that  are  emitted  by  the  region  statements  for  requesting  access  to  the  shared  resource.  The 
arbitration  process  emits  one  of  the  n  outputs  ai, . . .,  for  allowing  access  to  one  of  the  processes. 

We  will  now  explain  how  the  arbitration  process  works  without  going  into  details  of  the  Esterel  language  For  this 
reason,  we  translate  the  Esterel  program  to  a  finite  state  machine  by  means  of  the  Esterel  semantics  [2]  It  is  however 
reasonable  to  present  an  intermediate  result  of  the  translation  and  not  the  final  one.  In  particular,  we  consider  a  combination 
of  parallel  rumung  interacting  finite  state  machines  for  the  subsequent  Esterel  threads  of  the  arbitration  process  given  in 
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module  arbitratcAigi,  ■  ■ . ,  Qn,  fA,ai, . . . ,  a„): 
signal  ii, .  ..,tn,pi,. . .  ,Pn,arb  in 

loop 

abort  sustain  ti  when  arb; 

Hrotating  tokens  for  daisy  chain 

abort  sustain  when  arb 
end  loop 

il  ,  . 

loop 

weak  abort  halt  when  01  A 1 1 ;  /  j  setting  persistence 

weak  abort  sustain  pi  when  !  I  for  process  I 

end  loop 

II 


weak  abort  halt  when  Qn  ^tn’,  j  /setting  persistence 
Weak  abort  sustain  when  -tQn  / /for process  n 

end  loop 


loop 

weak  abort 
loop  emit  arb’, 

present  \/r=i(*j 

then  present 

case  01  A  ti  A  pi  do  emit  on; 


case  Qn  A  tn  A  pn  do  emit  q;„; 
end  present 
else  present 

case  01  do  emitai; 


/  /give  acknowledge 
/  /  when  arbitration  is 
/ /required 


case  Qn  do  emit  ck„  ; 
end  present 
end  present; 
pause 
end  loop 
when  Vr=i  ei\ 
weak  abort  halt  when  /a 
end  loop 
end  signal 
end  module 


Fig.  1.  Implementation  of  the  arbitration  process  in  Esterel 
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Figure  1 .  These  finite  state  machines  are  given  in  Figure  2.  Moreover,  we  define  for  i  e  {1, . . . ,  n}  the  output  signals  ai 
as  aj  arh  A  Qi  A  {ti  ApiV  static  A  Aj-=i  where  static  :=  Aj=i 

It  is  to  be  noted  that  this  translation  is  based  on  the  formal  semantics  of  Esterel  and  is  therefore  sound  wrt.  the  seman¬ 
tics  of  Esterel.  To  see  the  principle  of  the  translation,  we  list  the  translation  of  a  subsequent  thread  that  sets  the  persistence 
flagpfc. 


~^{QkAtk) 


loop 

weak  abort 

_ 1 _ 

loop 

weak  abort 

halt 

when  Qk  At  ki 
weak  abort 

QkAtk 

halt 

when  Qk  A  tkl 
weak  abort 

-  >■ 

- - — ■ 

sustain  pk 
when  -nQk 
end  loop 

-'Qk 

sustain  pk 
when  -ipfc 
end  loop 

_ 

_ / 

In  the  thread  for  setting  the  persistence  flag  p*,  there  are  two  progr^  locations  where  the  control  flow  rests  for  the  next 
point  of  time.  These  locations  are  indicated  by  a  hat  in  the  above  finite  state  machine.  It  is  easy  to  see  that  the  above  finite 
state  machine  matches  with  the  corresponding  one  given  in  Figure  2.  The  others  are  obtained  similarly. 

To  formally  reason  about  the  function  of  the  entire  arbitration  thread,  we  derive  now  transition  equations  of  the  boolean 
state  variables  according  to  Figure  2: 


init(ti)  ;=  1 
init(4)  :=  0 
init(pjt)  ;=  0 
init(or6)  1 


next(ii)  {arh  A  {-^arh  h) 
next(4)  :=  {arb  ->•  tk-i)  A  {-^arb  4) 
next(pfe)  :=  p*  A  {pk  V  4) 
next(ar6)  :=  {-^arb  A  /a)  V  {arb  A  -i  V"=i  Qj) 


static  A"=i  {ij  ~'Pj)  ock  arb  A  Qk  A  {tk  A  p*  V  static  A  A*=i  ~'Qj) 


Fig.  2.  Transition  diagram  for  the  finite  state  machine  of  the  arbitration  process 
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The  state  variables  tk  describe  a  ring  of  n  states  ti,  where  transitions  are  made  from  tk  to  ,,,0^  n)+i  whenever 
an  arbitration  decision  can  be  made.  This  models  a  round  robin  schema,  i.e.  there  is  a  rotating  token  associated  with  the 
region  statements;  we  say  a  region  statement  Rk  ‘has  the  token’  whenever  we  are  in  state  tk .  Note  that  at  each  point  of 
time,  exactly  one  of  the  boolean  state  variables  ti, ^ ,  tn  is  present. 

There  are  two  reasons  why  a  statement  Rk  may  be  granted  access  to  the  critical  region:  If  ak  holds,  then  we  have 
arb/\Qkf\tk  Apk  or  arb  A  Qk  A  static  A /\^~l  .  Both  cases  exclude  each  other:  First  assume  arbAQkAtk  Apk  holds. 

This  means  that  in  particular,  tk  A  Pk  holds,  and  hence  static  can  not  hold,  so  that  the  second  case  can  not  hold  either.  On 
the  other  hand,  assume  arb  A  Qk  A  static  A  A ~'Qj  holds.  Then,  static  holds,  that  implies  tk  ->■  -'Pk  ■  Thus  tk  A  Pk  can 
not  hold  which  would  be  necessary  to  satisfy  the  first  case. 

Therefore,  there  are  two  different  reasons  for  an  arbitration  decision:  firstly,  the  access  may  be  granted  by  static 
priorities.  If  static  holds,  then  the  region  statement  Ri  with  the  smallest  index  i  is  granted  to  execute  its  body.  Secondly, 
if  the  region  statement  Rk  that  currently  has  the  token  (tk  =  1)  has  set  its  persistence  flag  (pk  =  1),  the  static  priorities 
are  ignored  and  Rk  is  immediately  granted  access  to  the  critical  section.  The  persistence  flags  pk  are  used  to  establish  the 
fairness  of  the  arbitration:  whenever  Rk  request  for  accessing  the  region  (Qk  =  1)  the  request  remains  until  it  is  satisfied. 
Hence,  there  will  be  some  time  where  region  statement  Rk  receives  the  token  and  this  event  sets  the  persistence  flag  pk . 
If  Rk  is  not  granted  to  access  the  region  at  this  point  of  time,  the  token  will  rotate  another  round.  However,  if  the  request 
has  not  been  satisfied  when  the  token  returns  again  (this  implies  static  =  0,  since  Iwe  then  have  tk  A  Pk),  then  we  know 
that  Rk  has  been  ignored  at  least  for  the  last  n  arbitration  decisions  and  will  therefore  be  immediately  granted  access  to 
the  region.  This  assures  the  fairness  of  the  arbiter. 

While  a  region  statement  executes  its  body  statement,  no  further  arbitration  decisions  are  to  be  made.  For  this  reason, 
we  stop  the  rotation  of  the  token  during  this  time.  This  is  done  by  introducing  a  further  boolean  state  variable  arb  that 
is  false  iff  one  of  the  region  statement  executes  its  body  statement.  Arbitration  decisions  are  only  to  be  made  when  arb 
holds.  Initially,  arb  holds  since  none  of  the  region  statements  is  in  the  critical  section.  Then,  we  are  waiting  until  one  of 
the  processes  requests  for  the  access.  If  this  is  the  case,  one  of  these  region  statements  is  allowed  to  execute  its  body.^ 
Therefore,  arb  is  unset  and  remains  false  until  the  termination  signal  is  emitted  by  the  region  statement  that  has  been 
granted  access  to  the  critical  region. 


4  Verifying  the  Arbitration  Process 

Note  that  the  implementation  given  in  Figure  1  is  only  a  fixed  version  of  an  arbitration  process  that  can  be  replaced  by 
any  other  that  satisfies  the  following  requirements  that  we  present  in  temporal  logic  [11]: 

Exclusive;  At  each  point  of  time,  at  most  one  Rk  may  enter  the  critical  region: 


satisfied  request  persistent  request  immediate  decision 

Fairness:  The  arbitradon  is  fair,  if  we  assume  that  all  bodies  Si  terminate  and  if  all  entering  requests  persist  either  until 
they  are  granted  (or  forever): 

/  n  \  n  n 

^  I  V  I  A  ^  A  ^ 


termination 


persistent  request 


fairness 


^  We  will  prove  below  that  whenever  arb  and  some  of  the  gj  hold,  then  also  one  access  is  granted  at  the  same  point  of  time,  i.e.  one 
ai  holds. 
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The  latter  condition  is  very  subtle  and  is  therefore  explained  in  more  detail.  The  first  assumption  is  that  each  body  of 
each  region  statement  terminates  in  any  case.  Clearly,  if  this  did  not  hold,  we  would  not  be  able  to  guarantee  the  fairness. 
The  second  assumption  is  that  once  a  region  statement  requests  for  accessing  the  critical  region,  it  insists  on  requesting 
until  it  receives  a  grant  to  enter  the  critical  section.^  The  assumption  uses  a  weak  until  operation  which  means  that  the 
assumption  does  also  hold  when  the  region  statement  is  never  granted  access  to  the  critical  region.  The  fairness  condition 
proves  however  that  this  will  not  happen. 

To  verify  the  above  specification  for  an  arbitration  process  for  n  region  statements,  we  used  the  linear  time  temporal 
model  checker  implemented  at  our  institute  [12,13].  We  found  it  more  than  difficult  to  express  the  fairness  condition 
in  CTL,  so  that  the  use  of  the  LTL  frontend  was  really  necessary.  The  Exclusive  and  Only  Requested  conditions  of  our 
specification  have  been  checked  within  a  second,  so  that  we  do  not  list  detailed  runtimes  for  them.  The  experimental 
results  that  we  obtained  for  the  Immediate  Grant  and  Fairness  conditions  are  given  in  Figure  3  (SUN  Sparc  10, 300  MHz, 
Solaris  5.7, 640  MByte  main  memory). 


Fig.  3.  Runtimes  for  the  verification  of  the  arbitration  process 

The  automatic  verification  is  in  this  case  completely  sufficient:  we  are  able  to  verify  the  fairness  of  more  than  40 
region  statements  in  less  than  one  third  an  hour.  Therefore,  we  see  that  the  implementation  of  our  arbitration  process  lends 
itself  well  for  model  checking  techniques.  We  therefore  believe  that  also  Esterel  programs  with  mutual  exclusive  regions 
can  be  verified  efficiently  with  model  checking  techniques. 

5  Interactive  Proofs 

The  correctness  can  also  be  proven  by  means  of  a  theorem  prover  such  as  the  HOL  system  [14],  Again,  the  most  com¬ 
plicated  condition  to  prove  is  the  fairness  condition.  The  proof  of  the  fairness  runs  in  the  following  lines:  First  of  all,  it 
follows  fi:om  the  termination  of  the  body  statements  that  for  any  k  the  region  statement  Rk  will  receive  the  token  infinitely 
often,  i.e.  we  have  (1)  GFf*  for  any  k.  Now,  assume  there  exists  some  k  such  that  (2)  FG(^fc  A  -^a^)  holds,  i.e.,  after  some 
point  of  time  to  it  holds  forever  that  the  region  statement  Rk  requests  for  the  critical  region,  but  is  never  allowed  to  enter 
it.  As  Rk  will  receive  the  token  infinitely  often  (as  any  region  statement  does),  it  will  also  receive  the  token  after  to.  Let 
to  -I-  h  be  the  first  point  of  time  after  to  when  Rk  receives  the  token.  Then,  it  follows  that  the  persistence  flag  of  this 
region  statement  Rk  is  set  at  to  +  .  As  p*  holds  always  after  to  by  (2),  pk  remains  true  after  to  +  h  by  definition  of pk . 

*  It  is  easy  to  see  that  the  Pi's  of  section  2  implement  this. 
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However,  by  (1),  Rk  will  receive  the  token  also  infinitely  often  after  io  +  ,  so  let  fo  +  +  h  be  the  first  time  after  to  +  ti 

when  Rk  receives  the  token  again.  By  definition  of  the  grant  signals,  this  will  immediately  grant  Rk  access  to  the  region 
(as  now  arb  AQkAtkApk  holds).  Therefore,  we  obtain  a  contradiction,  so  that  (2)  must  be  false  and  the  arbitration  is  fair 
for  any  number  of  threads.  The  other  properties  are  easily  proved  by  a  simple  consideration  of  the  implementation  of  the 
thread  arbitrate  a  :  The  present  statements  allow  only  one  grant  at  a  time. 

As  a  result,  we  can  now  establish  a  proof  rule  for  the  verification  of  Esterel  programs  with  region  statements.  This  rule 
can  be  used  interactively  to  transform  verification  goals  with  Esterel  statements  with  region  statements  into  other  goals 
that  do  no  longer  contain  these  region  statements.  The  rule  is  simply  the  following,  where  ei, . . . ,  Pn,  /a,  ,  On  are 

disjoint  signals  that  do  neither  occur  in  S (i?i , . . . ,  iZ„)  nor  in 

S{Ri,...,Rn)  [=  $ 

'  ALi  G  (oik  ->  -'«j)  A 

Afe=l  G  (Qfc  ->  0a)  A 

5(Pi,...,P„)t=  G 

G  [[(vj=,  <»,)  ^  XF/.,]  ->  A?.,  -F(5  [e,  A  -.a,]] 

The  rule  is  to  be  read  as  follows;  Given  that  our  task  is  to  prove  that  an  Esterel  program  S (Pi , . . . ,  P„ )  that  contains  the 
region  statements  Pi , . . . ,  Pn  belonging  to  the  same  region  A  satisfies  the  property  #  which  may  be  given  in  a  first-order 
temporal  logic  formula  as  described  in  [15].  Then,  it  is  sufficient  to  prove  that  the  Esterel  program  S  (Pi , . . . ,  Pn)  satisfies 
the  property  where  we  can  use  as  additional  assumptions  the  above  listed  properties.  The  rule  simplifies  the  proof  task 
since  it  encodes  the  semantics  of  the  region  statements  by  replacing  them  with  corresponding  specifications.  Note  fiirther 
that  in  the  reduced  goal,  no  arbitration  process  occurs,  since  we  already  know  that  it  is  correct.  In  fact,  the  arbitration 
process  has  been  replaced  with  the  new  assumptions  that  can  therefore  be  viewed  as  an  declarative  form  of  our  arbiter. 

6  Conclusions  and  Future  Work 

We  have  shown  how  the  synchronous  language  Esterel  can  be  extended  by  a  new  statement  so  that  mutually  exclusive 
regions  are  provided  by  the  syntax.  We  have  moreover  shown  how  the  thereby  extended  Esterel  language  can  be  translated 
back  to  standard  Esterel  by  surrounding  the  critical  code  sections  by  a  simple  protocol,  and  adding  a  separate  arbitration 
thread  for  each  critical  section.  Also,  we  have  proved  the  correctness  of  this  arbitration  thread  by  means  of  model  checking 
the  temporal  logic  specifications  for  some  numbers  of  threads,  and  also  by  a  paper-and-pencil  proof  for  arbitrary  numbers 
of  threads.  In  particular,  we  have  proved  that  the  solution  is  safe,  i.e.,  at  any  point  of  time  any  critical  section  is  executed 
by  at  most  one  thread,  and  fair,  i.e.,  no  thread  must  wait  infinitely  long  for  accessing  the  critical  section  (provided  that  any 
thread  releases  the  section  after  a  finite  amount  of  time). 

Note,  however,  that  this  does  not  mean  that  there  are  no  deadlocks.  Clearly,  when  we  only  have  one  critical  section, 
i.e.,  if  all  region  statements  refer  to  the  same  critical  section,  then  we  can  state  that  the  program  is  free  of  deadlocks.  In 
case,  we  have  more  than  one  critical  section,  it  is  however  obvious,  that  deadlock  may  occur,  as  given  by  the  following 
simple  program: 


In  a  first  step,  the  left  hand  thread  requests  for  an  access  to  the  section  A,  while  the  right  hand  thread  request  for  an  access 
to  the  section  B.  If  there  are  no  other  requests,  the  arbitration  thread  for  section  A  will  grant  the  left  hand  thread  above  the 
access,  and  analogously,  will  the  right  hand  thread  receive  a  grant  to  access  section  B.  At  the  next  point  of  time,  however, 
the  left  hand  thread  above  requests  for  section  B,  while  the  right  hand  thread  requests  for  section  A,  Both  requests  can 
not  be  granted  since  both  arbitration  threads  are  now  not  in  arbitration  mode  since  both  sections  A  and  B  are  aheady 
accessed. 


region  A 
pause; 
region  B 

end  region 
end  region 


region  B 
pause; 
region  A 

end  region 
end  region 
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To  circumvent  these  problems,  we  plan  to  extend  the  region  statements  so  that  multiple  requests  are  possible  at  once 

i.e.,  we  allow  statements  ofthe  following  form:  qucsis  are  possmie  at  once, 

region  Ai,...,An  S  end  region 

m  protocol  code  Pi  for  replacing  such  statements  Ri  is  similar  to  the  one  given  here,  but  the  arbitration  is  now  more 
mphcated,  smce  we  must  now  consider  all  regions  in  a  single  arbitration  process.  If  we  then  forbid  nestings  of  these 
extended  region  statements,  we  can  agam  find  deadlock  free  arbitration  threads  similar  to  the  solution  ofthe  generalized 
dimng  philosophers  problem  as  given  in  [16], 


References 

2.  G.  Berry.  The  constructive  semantics  of  pure  Esterel,  May  1996 

3.  G.  Beny.  The  foundations  of  Esterel.  In  G.  Plotkin,  C.  Stirling,  and  M.  Tofte,  editors.  Proof,  Language  and  Interaction:  Essays  in 
Honour  of  Robin  Milner.  MIT  Press,  \99S. 

4.  E.  W.  Dijkstra.  Solution  of  a  problem  in  concurrent  programming  eontrol.  Comm.  ACM,  8(9)  569  1965 

p  43^1 12‘’’i9?8  sequential  processes.  In  F.  Genuys,  editor,  Programming  Languages,  Academic  Press,  New  York, 

6.  L.  Lamport,  A  new  solution  of  Dijkstra’s  concurrent  programming  problem.  Comm.  ACM,  1 7(8):453-455,  1974 

5(lk5Sri’983^  Lamport’s  concurrent  programming  problem.  ACM  Transactions  on  Progr.  Lang,  and  Systems, 

controller  synthesis  using  Esterel.  In  International  Workshop  on  Logic  Synthesis,  Lake  Tahoe, 
1993.  IEEE  Computer  Society  Press.  o  ,  , 

9.  H.  Toma,  E.  Sentovitch,  and  G.  Berry.  Latch  optimization  in  circuits  generated  from  high-level  descriptions.  In  lEEE/ACM 
International  Conference  on  Computer  Aided  Design  (ICCAD).  ACM/IEEE,  IEEE  Computer  Society  Press,  1996. 

10.  K.L.  McMillan.  Symbolic  Model  Checking.  Kluwer  Academic  Publishers,  Norwell  Massachusetts,  1993. 

11.  E.A.  EmCTSon  Temporal  and  Modal  Logic,  In  J.  van  Leeuwen,  editor.  Handbook  of  Theoretical  Computer  Science,  volume  B, 
pages  996-1072,  Amsterdam,  1990.  Elsevier  Science  Publishers. 

12.  K.  Schneider  CTL  and  equivalent  sublanguages  of  CTL*.  In  C.  Delgado  Kloos,  editor,  IFIP  Conference  on  Computer  Hardware 
Description  Languages  and  their  Applications  (CHDL),  pages  40-59,  Toledo, Spain,  April  1997.  IFIP,  Chapman  and  Hall 

13.  K.  Schneider  Model  checking  on  product  structures.  In  G.C.  Gopalakrishnan  and  P.J.  Windley,  editors.  Formal  Methods  in 

^^'Sn,yoUS22  oi  Lecture  Notes  in  Computer  Scienc,  pages  483-500,  Palo  Alto,  CA,  November  1998.  Springer 

14.  M.J.C.  Gordon  and  T.F,  Melham.  Introduction  to  HOL:  A  Theorem  Proving  Environment  for  Higher  Order  Logic  Cambridge 

Umversity  Press,  1993.  *  e 

15.  K.  Schneider  and  T.  Kropf.  The  C@S  system:  Combining  proof  strategies  for  system  verification.  In  T.  Kropf  editor  Formal 
HaMware  Verification  -  Methods  and  Systems  in  Comparison,  volume  1287  of  Lecture  Notes  in  Computer  Science,  pages  248- 

329.  Spnnger  Verlag,  state  of  the  art  report  edition,  August  1997. 

16.  K.M.  Chandry  and  J.  Misra.  Parallel  Program  Design:  A  Foundation.  Addison- Wesley,  1988. 


Experiences  with  the  Application  of  Symbolic  Model  Checking 
to  the  Analysis  of  Software  Specifications 


Richard  J.  Anderson,  Paul  Beame,  William  Chan,  and  David  Nothin 


Department  of  Computer  Science  and  Engineering, 
University  of  Washington 

Box  352350,  Seattle,  Washington  98195-2350,  USA  +1-206-543-1695 
{anderson,  beame,  wchan,  notkin}0cs. washington.edu 


Abstract 

Symbolic  model  checking  is  a  powerful  formal-verification  technique  which  has  been  used  to  analyze  many 
hardware  systems.  In  this  paper  we  present  our  experiences  in  applying  symbolic  model  checking  to  software 
specifications  of  reactive  systems.  We  have  conducted  two  in  depth  case  studies;  one,  using  the  specification  of 
TCAS  II  (Traffic  Alert  and  Collision  Avoidance  System  II),  and  the  other  using  a  model  of  an  aircraft  electrical 
system.  Based  on  these  case  studies,  we  have  gained  Significant  experience  in  how  model  checking  can  be  used 
in  to  analyze  software  specifications,  and  have  also  overcome  a  number  of  performance  bottlenecks  to  make  the 
analysis  tractable. 

The  emphasis  of  this  paper  is  the  uses  of  model  checking  in  the  analysis  of  specifications.  We  will  discuss 
the  types  of  properties  which  we  were  able  to  evaluate  in  our  case  studies.  These  include  specific  errors  we  were 
able  to  identify,  as  well  as  general  properties  we  were  able  to  establish  for  the  systems.  We  will  also  discuss, 
in  more  general  terms,  the  potential  uses  of  symbolic  model  checking  in  the  development  process  of  software 
specifications. 

Keywords 

Formal  methods,  formal  verification,  symbolic  model  checking,  binary  decision  diagrams,  software  specification, 
finite  state  representations. 

1  Specification  of  reactive  systems 

Reactive  systems  are  central  to  modern  technology.  Examples  of  their  deployment  range  from  air  traffic  control 
systems  to  advanced  medical  devices.  Since  they  are  often  deployed  in  safety  critical  applications  where  their 
malfunctioning  could  cause  significant  injury  or  loss  of  life,  their  correct  implementation  is  of  great  importance. 

In  studying  the  problem  of  how  to  better  design  these  systems,  we  concentrate  on  the  specification  level. 
Correct  specification  is  particularly  important,  since  it  is  widely  recognized  that  errors  introduced  early  in 
system  design  are  the  most  difficult  and  expensive  to  fix.  We  restrict  attention  to  specifications  which  are 
represented  as  finite  state  machines,  using  languages  such  as  statecharts  or  RSML. 

The  broad  goal  of  the  work  is  to  develop  techniques  that  allow  us  to  increase  our  confidence  in  specification. 
This  includes  being  able  to  show  that  specifications  obey  general  design  rules,  as  well  as  satisfy  particular 
domain  dependent  properties.  We  are  interested  in  incorporating  these  techniques  into  the  development  process 
of  the  specification  -  using  them  to  debug  the  specification  as  it  is  being  created,  as  opposed  to  just  using  them 
in  a  validation  phase  to  verify  the  specification  when  it  is  complete. 

2  Model  checking  technology 

Model  checking  is  a  formal  verification  technique  based  on  state  space  exploration.  Given  a  state  transition 
system  and  a  property,  model  checking  algorithms  exhaustively  explore  the  state  space  to  determine  whether 
the  system  satisfies  the  property.  Properties  are  often  expressed  in  a  temporal  logic  such  as  CTL  (Computation 
Tree  Logic)  [9].  An  important  aspect  of  model  checking  is  that  when  a  formula  is  discovered  to  be  false,  a 
counter  example  is  provided.  This  helps  with  the  understanding  of  the  source  of  the  error,  which  could  be  in 
the  model,  the  translation,  or  even  in  the  formula  being  evaluated. 
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A  natural  concern  about  model  checking,  is  that  since  the  entire  state  space  must  be  explored,  the  run 
time  of  algorithms  is  at  least  proportional  to  the  size  of  the  state  space,  which  is  potentially  enormous.  The 
breakthrough,  which  has  allowed  model  checking  to  be  applied  to  systems  with  much  larger  state  spaces,  was 
to  use  an  implicit  representation  of  that  that  space,  and  to  use  symbolic  techniques  for  exploration  [4, 16]. 
Instead  of  visiting  states  one  at  a  time,  symbolic  model  checkers  visit  sets  of  states  in  each  step.  The  underlying 
representation  which  is  generally  used  is  the  Binary  Decision  Diagram  (BDD)  [2].  In  many  practical  cases,  the 
size  of  the  BDDs  needed  to  represent  the  sets  of  states  used  in  the  model  checking  algorithm  is  small.  The  size 
of  the  BDDs  used  generally  determine  the  performance  of  the  algorithms.  Much  of  the  technical  model  checking 
literature  deals  with  the  issue  of  managing  BDD  size. 

Model  checking  was  first  used  in  the  analysis  of  hardware  designs,  and  is  now  recognized  as  an  important 
formal  tool  to  use  when  building  hardware  systems.  When  we  started  our  work  on  applying  model  checking  to 
software,  it  was  an  open  question  whether  or  not  model  checking  would  yield  interesting  results  on  software. 
There  was  a  belief  by  some  researchers  that  software  specifications  lacked  the  requisite  structure  to  allow  model 
checking  to  succeed.  However,  there  have  been  a  series  of  case  studies  by  ourselves  [5,6]  and  other  researchers  [1, 
10, 14, 19]  reporting  positive  results  for  applying  model  checking  to  software.  The  impetus  for  the  work  was  to 
determine  if  model  checking  could  be  used  to  analyze  software  specifications,  but  now  the  issue  has  shifted  to 
determining  how  to  get  the  most  leverage  in  using  model  checking  the  design  process. 


3  Application  of  model  checking  to  software 


The  question  of  the  feasibility  of  model  checking  can  be  phrased  in  a  number  of  ways.  We  distinguish  between 

these  to  emphasize  that  the  issue  is  not  “does  it  work  or  not”,  but  “how  can  the  technology  be  most  effective.” 

Modeling  the  system.  The  first  step  in  model  checking  is  to  translate  from  the  specification  language  (in  our 
case  RSML  [15]  or  Statecharts  [11])  to  the  representation  of  the  model  checker  (we  used  SMV  [16]).  When 
this  is  done,  the  basic  model  can  be  constructed,  and  a  reachable  state  space  is  computed.  It  is  possible 
that  the  initial  step  could  fail  because  of  BDD  size  explosion,  so  a  negative  result  could  be  reached  prior  to 
evaluating  any  formula.  In  our  case  studies,  we  had  to  do  a  substantial  amount  of  work  to  reach  the  point 
where  the  initial  construction  of  the  model  was  feasible. 

Evaluation  of  Properties.  The  second  step  in  establishing  feasibility  of  model  checking  is  to  show  that  there 
are  non-trivial  properties  which  can  be  evaluated.  The  standard  test  (to  claim  a  positive  result  for  model 
checking),  is  to  find  previously  undiscovered  bugs  in  the  specification  under  analysis.  Note  that  this  changes 
the  emphasis  to  falsification  -  the  desire  is  to  show  the  specification  does  not  work.  The  absence  of  falsifying 
examples  is  not  verification.  We  believe  that  this  will  be  one  of  the  major  uses  of  model  checking;  as 

•  a  debugging  tool  for  identifying  errors.  This  will  be  an  important  tool  to  improving  overall  quality  by 
augmenting  the  ways  that  errors  can  be  found.  We  discuss  below  various  types  of  properties  which  can  be 
evaluated. 

Range  of  Properties.  The  next  question  is  what  range  of  properties  can  be  evaluated.  There  are  limitations 
on  BBD  based  symbolic  model  checking  which  have  ramifications  on  the  types  of  properties  which  can  be 
checked.  For  example,  BDDs  Ho  a  poor  job  of  representing  multiplication,  which  limits  our  ability  to  check 
properties  which  involve  complicated  arithmetic. 

Performance.  The  performance  question  is  often  the  issue  between  a  check  being  feasible  and  infeasible. 
For  example,  our  first  successful  check  (of  a  trivial  property)  took  13  hours.  This  was  later  reduced  to 
just  minutes  by  modifying  the  algorithm.  In  many  situations,  the  tolerable  wait  for  a  result  is  probably 
measured  in  minutes  (because  of  interactive  use,  or  because  of  a  group  of  checks  being  performed  at  once. 

The  performance  of  the  algorithm  is  directly  correlated  with  the  size  of  the  intermediate  structures  which 
are  generated. 

Ease  of  use.  The  long  range  goal  is  to  develop  model  checking  technology  so  that  it  can  be  used  by  engineers 
who  are  not  experts  m  model  checking.  Our  work  has  not  reached  the  stage  where  this  can  be  assessed.  Our 
success  in  the  case  studies  required  modifying  the  underlying  model  cliecking  algorithms. 

Development  process.  Our  view  is  that  the  critical  question  is  how  to  use  model  checking  while  developing 
specifications.  One  can  imagine  a  development  methodology  where  a  set  of  invariants  are  maintained  as 
components  of  a  system  are  designed.  Components  can  initially  be  modeled  at  a  high  level  of  abstraction  - 
either  by  specifying  their  desired  behavior,  or  by  using  non-deterministic  devices. 


357 


_ Anderson  R.  J.  et  al.  Experiences  with  the  Application  of  Symbolic  Model  Checking 

4  Case  studies 

We  have  conducted  two  major  case  studies  where  we  applied  symbolic  model  checking  to  software  specifications. 
The  first  study  was  our  TCAS  study  [5],  and  the  second  involved  a  model  of  an  aircraft  electrical  system  [6]. 
The  second  study  was  done  in  collaboration  with  engineers  from  the  Boeing  Corporation.  These  studies  both 
involved  large,  real  world  specifications,  written  by  other  people.  Size  was  an  important  issue,  since  we  wanted 
to  validate  the  technique  on  specifications  of  commercial  scale,  as  opposed  to  just  on  toy  problems. 

4.1  TCAS 

TCAS  II  is  an  airborne  collision  avoidance  system  required  by  the  United  States  Federal  Aviation  Administra¬ 
tion  (FAA)  on  most  commercial  aircraft  that  enter  U.S.  airspace.  The  TCAS-equipped  aircraft  is  surrounded 
by  a  protected  volume  of  airspace.  When  another  aircraft  intrudes  into  this  volume,  TCAS  II  generates  warn¬ 
ings  (traffic  advisories)  and  suggests  possible  escape  maneuvers  (resolution  advisories,  or  RAs)  in  the  vertical 
direction  to  the  pilot. 

The  system  requirements  specification  of  TCAS  II,  a  400-page  document,  was  written  in  RSML.  The  first 
obstacle  to  analysis  was  its  sheer  size.  As  a  first  attempt  we  decided  to  try'  to  verify  a  portion  of  it,  namely 
a  state  machine  called.  Own-Aircraft  ,  which  occupies  about  30%  of  the  specification.  Own- Aircraft  has  close 
interactions  with  another  state  machine  called  Other-Aircraft  ,  which  tracks  the  state  of  other  aircraft  in  the 
vicinity  and  possibly  generates  RAs.  Up  to  thirty  other  aircraft  can  be  tracked.  Prom  the  RAs  given  by  all  the 
instances  of  Other- Aircraft  ,  Own- Aircraft  derives  a  composite  RA  and  generates  visual  and  audio  outputs  to 
the  pilot. 

We  were  able  to  evaluate  various  properties  of  the  specification,  including  some  which  revealed  errors  in  the 
specification^ .  One  example  was  testing  the  following: 

AG  ( (Composite-RA  =  Climb 

&  Composite-RA-Evaluated-Event) 

->  Displayed-Model-Goal  >=  1500) 

A  pilot  receives  two  different  outputs  from  TCAS  when  being  given  instructions  on  avoiding  another  aircraft: 
an  action  (Climb  or  Descend),  and  a  desired  altitude  rate  of  change.  The  query  is  checking  that  when  the  pilot 
is  instructed  to  climb,  the  rate  of  altitude  change  is  positive.  There  was  a  fairly  complicated  counterexample  to 
this,  which  involved  an  intruder  aircraft  changing  its  climb  rate  in  adjacent  time  intervals.  Further  discussion 
of  the  properties  we  were  able  to  check  is  given  below. 

We  now  mention  a' few  of  the  major  steps  in  the  analysis.  We  made  significant  use  of  non-determinism  in  our 
analysis.  This  means  that  some  of  the  state  machines  were  represented  as  machines  which  could  make  arbitrary 
transitions,  instead  of  the  transitions  made  in  the  specification.  Using  non-deterministic  machines  means  that 
the  analysis  is  conservative  with  respect  to  safety  properties.  Using  non-determinism  allowed  us  to  apply  model 
checking  in  an  incremental  fashion:  we  only  needed  to  have  portions  of  the  system  translated  in  order  to  check 
properties,  and  we  could  refine  our  translation  in  response  to  results  of  the  model  checker.  (This  was  important, 
since  it  allowed  us  to  catch  errors  in  our  translation).  There  were  portions  of  the  system,  involving  multiplication 
and  division  in  the  transition  relation  which  we  were  not  able  to  model.  We  replaced  these  by  non-deterministic 
operators,  which  gave  a  superset  of  possible  transition.  Again,  this  was  done  so  that  we  could  evaluate  properties 
without  having  a  complete  model  of  the  system. 

State  machines  are  a  natural  model  for  reactive  systems  which  interact  with  the  outside  world.  The  inputs  to 
the  system  are  external  events.  In  TCAS,  an  example  of  an  external  event  is  a  transponder  signal  received  from 
another  aircraft.  State  machines  also  generate  internal  events  which  are  used  to  communicate  between  different 
submachines.  There  has  been  much  discussion  of  the  semantics  of  these  different  types  of  events  [13,18,12]. 
One  issue  is  whether  the  internal  events  can  be  active  when  there  are  external  events  received.  The  TCAS 
model  (using  RSML)  uses  the  synchrony  hypothesis,  which  is  that  all  internal  events  are  processed  between 
external  events.  One  way  of  viewing  this  is  that  internal  events  are  infinitely  faster  than  external  events.  (This  is 
reasonable  for  systems  such  as  TCAS,  where  the  separation  of  external  events  is  measured  in  seconds).  To  model 
synchronization,  a  state  variable  stable  is  introduced  to  keep  track  of  when  there  are  active  internal  events. 
The  handling  of  synchronization  has  a  major  impact  on  the  performance  of  the  model  checking  algorithms. 

A  major  difference  between  the  TCAS  specification  and  many  hardware  specification  is  that  some  of  the 
transition  rules  in  TCAS  depend  on  arithmetic  operations.  Examples  include  comparing  altitudes  to  determine 

^  We  were  working  with  a  preliminary  version  of  the  specification  (Versiou  6.00,  March  1993).  We  do  not  know  if  the 
issues  are  present  in  later  versions  of  the  specification. 
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separation,  and  estimating  positions  based  upon  velocities  and  accelerations.  Arithmetic  involving  addition  and 
comparison  can  be  handled,  provided  that  it  is  represented  at  the  bit-wise  level,  and  the  bits  are  interleaved 
approprmtely.  However,  multiplication  operations  are  not  amenable  to  BDD  representation  [3],  and  this  did  limit 
t  e  portions  of  the  specification  that  we  could  analyze.  Proper  handling  of  multiplication  is  an  open  problem  In 

other  work,  we  have  attempted  to  integrate  constraint  solving  and  model  checking  to  handle  transitions  based 
on  multiplications  [7]. 


4.2  Aircraft  Electrical  System 

Our  second  case  study  was  an  analysis  of  a  statecharts  model  of  the  electrical  power  distribution  (EPD)  system 
on  the  Boeing  777  aircraft.  We  stress  that  the  statecharts  model  was  developed  for  research  purposes  and  does 
not  represent  the  actual  requirements  used  to  develop  the  on-board  system.  As  such  the  model  bv  intent  did  not 
include  all  the  logic  necessary  for  a  complete  specification.  The  model  was  intended  as  a  high-level  abstraction 
of  the  electrical  system,  which  included  only  the  logic  necessary  to  accomplish  the  goals  of  a  wider  airplane 
system  analysis  [17].  . 

The  purpose  of  the  EPD  system  is  to  distribute  AC  and  DC  power  to  other  airplane  systems.  It  comprises 
separate  interconnected  distribution  systems  including  main  AC  power,  backup  AC  power,  DC  power,  standby 
power,  and  flight  controls  power.  Electrical  power  is  distributed  from  power  sources  to  power  busses  via  a 
number  of  relayed  circuit  breakers.  Failures  of  the  power  sources  or  circuit  breakers  are  automatically  detected 
and  isolated.  We  focus  on  the  pbrtion  of  the  statecharts  that  models  the  main  and  backup  AC  distribution 
subsystems. 

One  of  the  requirements  of  the  electrical  sj^stem  was  that  it  supports  a  degree  of  redundancy  -  components 
should  remain  powered  in  spite  of  several  failures.  Checks  contingent  on  a  number  of  failures  could  easily  be 
represented  in  the  logic,  so  we  were  able  to  evaluate  various  fault  tolerant  properties. 

Two  properties  we  checked  were  “Not  only  should  the  busses  be  powered  when  there  are  no  failures,  they 
should  be  powered  by  different  sources”  and  “The  main  busses  should  in  fact  tolerate  one  failure  in  the  power 
sources  or  circuit  breakers  using  the  formulas 

AG  ((Stable  &  No-Failures) 

->  Separate-Sources) 

and 

AG  ((Stable  &  At-Most-l-Failure)  ->  main) 

respectively.  Both  of  these  properties  failed  for  essentially,  the  same  reason:  there  was  a  subtle  modeling  flaw  in 
specifying  the  circuit  breaker.  The  failure  of  a  circuit  breaker  and  its  subsequent  recovering  were  represented  as 
boolean  variables,  and  not  as  events,  so  a  transistion  was  not  made  inside  the  circuit  breaker  after  its  recovery, 
and  It  was  left  in  an  incorrect  state.  The  scenerios  to  trigger  the  error  were  moderately  involved.  For  example,' 
in  the  second  example  it  involves  a  failure  in  a  circuit  breaker,  a  change  in  inputs  to  induce  a  state  change  in 
its  controller,  the  circuit  breaker’s  recovery,  and  a  subsequent  failure  in  one  of  the  powder  sources. 


5  Uses  of  model  checking 

I 

The  prime  use  of  model  checking' is  as  a  debugging  tool.  Specific  properties  are  tested,  and  when  a  violation  is 
found,  a  counter  example  is  given.  In  contrast  to  verification,  model  checking  is  used  to  find  errors,  not  prove 
correctness.  Model  checking  can  be  used  in  conjunction  with  other  testing  methods  (such  as  simulation)  to  gain 
confidence  that  errors  have  been  found  and  eliminated. 

A  fundamental  question  in  applying  model  checking  is  “What  to  check?”.  Our  experience  is  that  the  prop¬ 
erties  of  interest  divide  into  tw'o  broad  classes:  domain  dependent,  which  require  understanding  of  the  domain, 
and  domain  independent,  w^hich  can  be  considered  as  “design  rules”  for  specifications. 

5.1  Domain  dependent  properties  ‘ 

A  key  to  our  success  in  the  two  case  studies  was  access  to  experts  on  the  systems  that  we  were  wwking  with 
We  would  not  have  been  able  to  identify  the  properties  to  evaluate  for  the  TCAS  study  without  this  expertise 
Issues  such  as  looking  checking  the  consistency  of  the  outputs  to  the  pilot  (advisor  and  climb  rate)  would  not 
lave  occurred  to  us.  The  understanding  of  counterexamples  also  required  significant  domain  knowdedge.  It  was 
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necessary  to  thoroughly  understand  the  counterexamples  in  order  to  determine  the  type  of  the  error.  We  do  not 
believe  that  it  will  be  possible  to  reduce  the  role  of  the  domain  expert  in  the  model  checking  process. 

In  our  study  of  the  aircraft  electrical  system,  we  also  worked  with  domain  experts  (the  designers  of  the 
model).  In  this  study,  the  properties  to  test  were  more  accessible.  We  had  a  document  which  outlined  a  set  of  fault 
tolerance  requirements.  These  were  phrased  in  terms  of  probability  of  failure,  but  there  was  a  correspondance 
between  this  and  bounding  the  number  of  simultaneous  failures.  Expertise  was  still  necessary  in  order  to  clarify 
several  of  the  properties  that  had  to  be  tested.  Model  checking  turned  out  to  be  an  excellent  tool  to  use  for  the 
evaluation  of  fault  tolerance,  since  the  number  of  failures  could  be  included  in  the  precondition  of  the  property 
being  checked. 


5.2  Domain  independent  properties 

Domain  independent  properties  can  be  viewed  as  design  rules  that  specifications  should  satisfy.  An  example  of 
a  property  that  is  quite  easy  to  check  is  whether  the  state  transitions  are  deterministic:  is  it  the  case  that  every 
state  can  have  at  most  bne  transistion  enabled  at  a  time.  This  can  be  tested  by  defining  a  property  which  tests 
for  simultaneoulsy  active  transitions  in  reachable  states.  The  reason  why  it  is  generally  argued  that  deterministic 
transitions  are  important  is  that  if  there  is  a  choice  in  the  behavior,  then  diflferent  implementations  may  behave 
differently.  A  related  property  is  “function  consistency”.  If  a  function  is  defined  in  terms  of  cases,  it  is  natural 
require  that  the  cases  are  mutually  disjoint.  Discussions  of  other  domain  independent  properties  can  be  found 
in  our  papers  [5,6]. 

6  Performance 

Both  of  our  case  studies  involved  large  specifications  which  generated  models  which  were  close  to  the  maximum 
size  which  could  be  evaluated  with  a  model  checker.  In  the  TCAS  study,  the  model  had  a  global  state  space 
with  227  Boolean  variables,  10  of  which  are  for  events,  36  for  the  states  of  Own- Aircraft  ,  19  for  the  states  of 
Other-Aircraft  ,  134  for  altitude  and  altitude  rates,  22  for  inputs  other  than  altitude  and  altitude  rates,  and 
6  for  other  purposes.  The  size  of  the  state  space  is  about  1.4  x  10®®.  The  size  of  the  reachable  state  space  is 
at  least  9.6  x  10®®.  In  the  electrical  system  study,  there  are  33  two-state  machines,  23  Boolean  inputs,  and  34 
events,  for  a  total  of  90  Boolean  state  variables,  or  about  10^^  global  states,  of  which  at  least  10^®  are  reachable. 

Our  general  experience  is  that  the  performance  question  is  between  feasibility  and  infeasibility  as  opposed 
to  optimizing  performance.  Most  of  our  successful  checks  ran  in  under  10  minutes  using  about  10  megabytes  of 
memory.  Unsuccessful  checks  were  usually  terminated  after  several  hours.  Failing  computations  generally  had 
excessively  large  internal  (BDD)  representations. 

Our  initial  attempts  to  check  formulas  in  both  the  TCAS  and  the  EPD  studies  were  unsuccessful.  In  both 
cases  we  were  forced  to  make  significant  changes  to  model  checking  algorithm,  and  to  our  methods  of  translating 
from  the  state  machine  model  to  the  representation  for  the  model  checker.  More  detailed  descriptions  of  our 
performance  enhancements  can  be  found  in  our  papers:  [5,8,6].  Our  methods  for  addressing  the  performance 
problems  have  included:  ' 

Bitwise  arithmetic  The  order  of  variables  in  a  BDD  can  influence  it’s  size.  We  needed  to  interleave  the 
variables  corresponding  to  the  bits  of  binary  data.  This  was  done  by  a  transformation  which  was  applied 
when  compiling  to  the  source  language  of  SMV. 

Search  Order  We  found  it  necessary  to  modify  the  search  algorithms  used  by  SMV.  One  modification  involved 
storing  information  during  a  forward  search  to  make  generation  of  counter  examples  more  efficient.  The 
choice  between  forward  search  and  backwards  search  was  often  important. 

Short  circuiting  This  technique  reduced  the  number  of  BBD’s  generated  by  stopping  the  iterations  before  a 
fixed  point  was  reached. 

Making  exclusive  events  explicit  This  allowed  backwards  search  to  be  performed  much  more  efficiently 
reducing  the  size  of  BDD’s. 

Partitioning  strategies  One  of  the  ways  to  reduce  the  size  of  the  BDD  for  the  transition  relation  is  to 
decompose  it  several  BBD’s  with  disjunctive  or  conjunctive  partitioning  [4]. 

Abstraction  One  abstraction  technique  that  we  applied  was  to  identify  portions  of  the  system  the  were  not 
relevent  to  a  check  (with  a  conservative  analysis),  and  remove  that  part  of  the  system  to  reduce  the  size  of 
the  model.  One  of  the  keys  to  making  this  work  well  is  to  be  able  to  identify  false  dependencies. 
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Synchronization  Our  representation  of  state  machines  distinguihed  between  macrosteps  (for  outside  events) 
and  microsteps  (for  internal  events).  Inside  a  macrostep,  all  internal  events  would  be  executed,  so  the  next 
macrostep  could  not  start  until  no  more  internal  events  could  be  generated.  We  discovered  that  performance 
could  be  ^eatly  improved  if  we  made  the  synchronization  process  as  regular  as  possible,  even  at  the  expense 
of  mcreasing  the  number  of  states,  or  the  lengths  of  event  chains. 

7  Conclusions 

The  goal  of  our  work  has  been  to  show  that  symbolic  model  checking  can  be  used  in  the  analysis  of  software 
specifications.  We  have  conducted  case  studies  on  real  specifications,  and  have  had  success  in  identifying  errors  in 
the  pecifications  that  were  not  previously  known.  We  have  also  developed  techniques  improve  the  performance 
of  the  model  checking  algorithms,  and  allow  checks  to  be  made  which  were  previously  intractable.  We  are 
optimmistic  about  the  future  of  model  checking  in  the  software  development  process.  There  is  still  much  vwk 
o  do  in  refining  the  algorithms  and  developing  tool  support  for  software  model  checking,  but  there  is  a  growing 
body  of  evidence  that  model  checking  is  applicable  in  the  software  domain  as  well  as  in  the  hardware  domain. 
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Abstract.  This  paper  reports  on  a  non-trivial  case-study  carried  out  in  the  context  oii  the  German  cor¬ 
rect  compiler  construction  project  Verifix.  The  PVS  system  is  here  used  as  a  vehicle  to  formally  represent 
and  verify  a  generic  checker  routine  (run-time  result  verification)  used  in  compiler  back-ends.  The  checker 
verifies  the  results  of  a  sophisticated  labeling  process  of  intermediate  language  expression  trees  with  in¬ 
stances  of  compilation  rule  schemata.  Starting  from  an  operational  specification  (i.e.  a  set  of  recursive  PVS 
functions),  necessary  declarative  properties  of  the  checker  are  formally  stated  and  proved  correct. 

Ke3cwords:  formal  verification,  checker-based  program  verification,  generic  specification 


1  Introduction 

The  German  project  Verifix  on  compiler  verification  aims  at  developing  innovative  methods  for  the  construction 
of  correct  realistic  compilers  for  practically  relevant  source  languages  and  concrete  target  architectures.  Correct 
execution  of  source  programs  depends  on  the  correctness  of  the  binary  machine  code  executable,  thus  either  the 
final  executable  has  to  be  verified  or  the  compiler  used  is  to  be  shown  correct  [3]. 

A  realistic  state-of-the-art  compiler  is  a  large  and  complex  program  system  consisting  of  many  hard,  highly 
optimizing  algorithms  which  are  difficult  to  verify  since  mathematical  inductive  arguments  often  fail.  For  ex¬ 
ample,  the  code  generation  phase  of  a  compiler  often  uses  clever  routines  for  register  allocation,  instruction 
scheduling  or  pipeline  optimizations.  For  this  reason,  a  more  practical  modular  approach  is  taken:  we  use  a 
checker-based  approach  to  program  verification,  which  works  if  partial  correctness  suffices  (i.e.  rather  no  result 
than  a  wrong  result).  It  is  often  much  easier  to  check  the  correctness  of  a  given  result  at  run  time  than  to  verify 
the  generating  alprithm  and  its  implementation.  In  our  case,  for  instance,  we  would  rather  check  that  every 
assigned  register  is  free  and  available  than  totally  verify  the  sophisticated  register  allocation  algorithm.  Thus, 
one  can  concentrate  on  the  verification  of  (in  general)  small  checking  (filter)  routines  built  into  the  code  in 
order  to  establish  partial  correctness  of  the  entire  program.  Of  course,  this  only  makes  sense  if  the  verification 
of  the  checker  is  indeed  easier  than  the  verification  of  the  program  whose  results  are  checked  [4,6].  Checkers 
have  been  used  to  ensure  type  correctness  properties  of  a  C  subset  compiler  [7]  and  to  verify  the  compilation  of 
synchronous  languages  to  C  [9],  but  not  yet  to  “verify”  totally  a  machine  code  generation  procedure. 

In  this  paper  the  PVS  specification  and  verification  system  is  utilized  to  formally  verify  the  specification  of 
such  a  checker  program  to  be  used  in  the  back-end  part  of  a  compiler.  The  back-end  translates  linear  intermediate 
code  (i.e.  sequence  of  assignments  of  expressions)  into  linear  assembly  code.  This  back-end  is  to  be  generated 
from  a  set  of  local  translation  rule  schemata  and  additional  components  such  as  optimized  register  allocators  and 
schedulers.  The  rule  schemata  were  independently  verified  with  respect  to  source  and  target  language  semantics 

The  part  of  the  compiler  we  are  to  check  gets  as  input  an  intermediate  language  expression  tree  and  outputs 
a  labeled  expression  tree.  The  labels  consist  of  the  rule  used  to  compute  the  node,  assignments  of  the  register 
and  numerical  variables  to  actual  registers  and  values  respectively,  as  well  as  the  schedule  number  of  the  rule. 

Our  formalization  is  generic  with  respect  to  the  languages  and  translation  rules.  It  is  realized  as  a  parame¬ 
terized  PVS  theory.  The  specification  being  written  in  an  operational  style  is  executable  within  the  prover.  It 
has  been  applied  to  a  small  realistic  example  of  translation  from  the  intermediate  language  MIS  to  DEC  Aloha 
assembly  code.  ^ 

We  present  these  results  as  follows:  the  next  section  gives  a  brief  introduction  to  PVS.  Sect.  3  outlines  the 
principle  of  generator-based  back-end  generation.  In  Sect.  4  the  PVS  formalization  of  the  checker  is  presented 
*  This  work  has  been  supported  by  the  Deutsche  Forschungsgemeinschaft  (DFG)  project  Verifix 
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and  declarative  correctness  properties  are  stated,  formalized  and  proved  correct.  All  PVS  theories  and  proof 
scripts  are  available  from  the  authors  upon  request. 

2  A  Brief  Introduction  to  PVS 

The  PVS  system  [8]  combines  an  expressive  specification  language  with  an  interactive  prover /proof  checker.  The 
PVS  specification  language  builds  on  classical  typed  higher-order  logic  with  the  usual  base  types,  bool,  nat, 
among  others,  the  product  type  constructor  [A  ,B]  and  the  function  type  constructor  [A->B] .  The  type  system  of 
PVS  is  augmented  with  dependent  types  and  abstract  data  types.  The  special  type  TYPE  designates  an  unspecified 
type,  and  TYPE+  an  unspecified  non  empty  type.  A  distinctive  feature  of  the  PVS  specification  language  are 
predicate  subtypes-,  the  subtype  {x:  A  |  P(x) }  consists  of  exactly  those  elements  of  type  A  satisfying  predicate 
P.  Predicate  subtypes  are  used,  for  instance,  for  explicitly  constraining  the  domains  and  ranges  of  operations  in 
a  specification  and  to  define  partial  functions.  Sets  are  identified  with  their  characteristic  predicates,  and  thus 
the  expressions  predCA]  and  set  [A]  are  interchangeable.  For  a  predicate  P  of  type  pred[A]  ,  the  notation  (P) 
is  just  an  abbreviatioii  for  the  predicate  subtype  {x:A  I  P(x)}. 

In  general,  type-checking  with  predicate  subtypes  is  undecidable;  the  type-checker  generates  proof  obliga¬ 
tions,  so-called  type  correctness  conditions  (TCCs)  in  cases  where  type  conflicts  cannot  immediately  be  resolved. 
A  PVS  expression  is  not  considered  to  be  fully  type-checked  unless  all  generated  TCCs  have  been  proved.  PVS 
only  allows  total  functions,  hence  it  must  be  ensured  that  all  (recursive)  functions  terminate.  For  this  purpose, 
a  well-founded  ordering  or  a  measure  function  is  used.  The  definition  of  a  recursive  function  f  generates  a  TCC 
which  states  that  the  measure  function  applied  to  the  recursive  arguments  decreases  with  respect  to  a  well- 
founded  ordering.  A  built-in  prelude  and  loadable  libraries  provide  standard  specifications  and  proved  facts  for 
a  large  number  of  theories  (we  use  for  instance  the  f  inite_set  type,  the  upto  and  subrange  subtypes  of  nat, 
the  empty?  predicate  over  sets,  the  choose  function  to  extract  an  element  from  a  set,  etc. . .).  Specifications 
axe  realized  as  possibly  parameterized  PVS  theories  and  theory  parameters  can  be  constrained  by  means  of 
assumptions.  When  instantiating  a  parameterized  theory,  TCC’s  are  automatically  generated  according  to  the 
assumptions. 

Proofs  in  PVS  are  presented  in  a  sequent  calculus.  There  exists  a  large  number  of  atomic  commands  (for 
quantifier  instantiation,  automatic  conditional  rewriting,  induction,  etc. . . )  and  built-in  strategies  generating 
proofs  for  the  easiest  subgoals  automatically. 

3  Back-end  Generation  by  Term  Rewriting 

The  back-end  of  a  compiler  is  the  part  of  the  program  in  charge  of  the  final  translation  from  a  low-level 
intermediate  language  to  assembly  or  machine  code  (this  phase  is  usually  called  code  generation).  Its  main  task 
is  to  generate  sequences  of  target  level  instructions  to  compute  the  value  of  intermediate  language  expressions. 
The  state-of-the-art  code  generators  are  themselves  generated  from  a  set  of  optimized  translation  rules  schemata 
and  include  complex  mechanisms  for  optimal  rule  selection,  register  allocation  and  operation  scheduling. 

The  rule  schemata  are  local  translation  rules  associating  a  sequence  of  assembly  code  to  an  expression 
subtree,  the  latter  being  arbitrarily  complex  depending  on  the  level  of  resource  and  time  optimization.  They  are 
parameterized  by  use  of  variables  in  place  of  registers  and  constants,  and  the  set  of  registers  or  register  variables 
used  in  input,  output  and  temporary  storage  (in  the  generated  code)  are  given.  These  rules  are  mechanically 
proved  correct  with  respect  to  the  semantics  of  the  intermediate  and  target  languages  independently  from  the 
whole  process  in  PVS  using  a  user  defined  strategy  [1]. 

As  already  stated,  we  want  to  avoid  the  verification  of  the  specification,  let  alone  the  implementation,  of  the 
rule  selector/allocator/scheduler  taking  care  of  the  labeling  of  the  expression  trees.  This  is  possible  by  verifying 
the  output  of  the  procedure  at  run  time,  aborting  the  compilation  if  ever  an  error  occurs  (giving  the  available 
elements  for  the  correction  of  the  bug).  The  checking  procedure  must  however  be  proven  to  detect  any  case 
where  the  code  that  will  further  be  generated  from  the  labeled  tree  will  not  exactly  implement  the  computation 
of  the  translated  expression. 

Figure  1  gives  an  overview  of  the  compilation  process.  As  illustrated,  the  back-end  generator  must  be  partly 
verified  to  make  sure  that  the  verified  code  it  uses  is  not  altered  in  any  way,  and  that  the  components  on 
the  correctness  critical  path  are  correctly  connected.  The  generated  back-end  contains  non  verified  code  whose 
results  will  be  checked  at  run  time  by  the  verified  checker. 

The  straightforward  way  to  make  sure  that  the  labeling  was  correctly  done  is  to  extract  the  code  of  the  labeled 
tree  according  to  the  schedule,  and  show  that  this  code  implements  the  computation  of  the  initial  expression. 
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* 


back  end 
genetic 
rules 

[backend  1 
(generatorJ 

(trusted) 


Oyerviow  of  the  compilation  with  detailed  back-end  principle 


This  is  clearly  unpracticable  at  runtime,  as  we  would  have  to  deal  with  the  semantics  of  the  languages  But  the 
rule  schemata  were  already  proved  correct,  and  thus  the  translation  will  be  correct  if  the  rules  are  “properly” 
used.  The  proper  use  of  a  rule  being  hard  to  define  formally,  we  will  verify  properties  that  are  intuitively 
needed  and  give  elements  to  show  that  these  properties  actually  imply  a  correct  resulting  code  given  a  correct 
implementation  of  the  code  extractor. 

The  labeling  process  actually  represents  a  covering  of  the  expression  tree  with  instances  of  the  expression 
trees  of  the  translation  rules  used,  each  of  the  rule  trees  being  rooted  at  the  node  for  which  the  rule  is  applied 
(as  the  expression  part  of  the  rules  may  be  a  single  unary  operator  as  well  as  a  complex  expression). 

_  The  correctness  requirements  of  this  process  are  to  make  sure  the  covering  is  correct  (every  expression  node 
K  covered  with  a  rule  node  with  a  correct  operator),  to  verify  the  schedule  (subterms  must  computed  before 
their  use),  to  verify  the  value  passing  from  children  to  parent  rule  (output  register  of  the'child  rule  is  the  same 
as  the  corresponding  input  register  of  the  parent  rule  -  via  assignment  of  register  variables)  and  to  verify  that 
the  values  computed  are  not  overwritten  before  their  use. 

Let  us  continue  with  an  example  exposed  in  [10].  The  source  language  statement  V  :=V  +  1  will  be  compiled 
to  the  following  MIS  expression  (the  storage  address  of  V  being  8  relatively  to  the  local  pointer  -  which  is  stored 
in  register  1  on  the  DEC- Alpha): 

intassign(local{intconst{8)),intaddicontent(local{intconst(8)}),intconst{l))) 

and  this  expression  will  be  compiled  using  the  following  rule  schemata  (remark  the  encoding  size  of  constant 
opGr&tors )  r 

rulel  :  intassign{local{intconsm{i)),reg{X))  ->■  •;  STQ(X,i,  1)  ' 
rule2  :  intadd{reg{X),  intconsm{i))  Y;  ADDI{X,  i,  Y,  Q) 
rules  :  contentilocal{intconstl6{i)))  E;  LDQ{1,  i,  Y) 
to  the  following  DEC- Alpha  code: 

LDQ{1, 8, 3);  ADDIiS,  1, 3,  Q);  5rQ(3, 8, 1) 


Fi^re  2  sketches  the  problem  of  verifying  value  passing  between  the  codes  generated  for  a  sub-expression 
^d  the  top  operator.  As  one  would  expect,  the  three  expression  trees  and  the  two  assignments  involved  make 
this  verification  somewhat  complex.  This  lead  us  to  define  an  operational  formulation  of  this  verification  process 
and  similar  specifications  for  the  others  properties.  ’ 

are  hardly  usable  as  is  in  a  proof  context,  thus  more  declarative  properties  have  been 
toure  proofs'"''  successfully  checked.  These  properties  shall  be  the  basis  for  all 
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(  resW  )  (inleOTSt16(l))f^“i^':^' 


(content  )  fuleS 
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^ — — I - '  temp:  -  ‘ 
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Fig.  2.  Verification  of  value  passing 


4  Formalization  of  the  Checker 

We  tried  to  keep  the  specification  as  generic  as  possible  by  abstracting  over  the  syntax  and  structures.  We  had 
though  to  select  a  proper  structure  for  the  expression  trees  in  order  to  be  able  to  use  induction  in  the  proofs.  We 
defined  the  abstract  datatype  Tree  (nodes  have  a  value,  a  left  and  a  right  son,  leaves  are  terminal)  parameterized 
by  the  type  of  the  values  of  the  nodes  and  PVS  generated  the  induction  theorems  for  this  structure.  We  used  this 
type  for  both  the  labeled  trees  and  rule  trees  encoding.  The  parameterization  of  our  PVS  theory  is  presented 
in  Fig.  3. 

The  four  verifications  described  in  the  previous  section  are  undertaken  by  four  independent  predicates 
(functions  of  type  [Node->bool]):  covercheck?,  schedulecheck?,  valuecheck?  and  overwritecheck?.  Some 
of  these  predicates  have  a  straightforward  formulation  with  mutually  recursive  functions.  Unfortunately,  the 
PVS  system  does  not  support  mutual  recursive  functions  due  to  termination  problems.  We  therefore  wrote 
them  using  a  single  recursive  function  with  a  flag  indicating  which  of  the  bodies  is  to  be  evaluated.  Termination 
of  these  functions  is  ensured  by  a  measure  function  using  a  lexicographical  ordering  of  the  flag  and  the  measure 
functions  of  the  bodies.  Figure  4  presents  the  PVS  code  for  the  valuecheck?  predicate. 

As  stated  before,  these  operational  formulations  of  the  checkers  with  their  flagged  recursion  schemes  are 
hardly  usable  in  a  proof  context,  and  is  therefore  not  very  helpful  to  establish  the  correctness  of  the  back-end. 
To  prove  that  the  code  to  be  generated  from  the  labeled  tree  will  actually  implement  the  expression  compiled,  we 
will  have  to  induct  on  the  number  of  code  extraction  steps  and  therefore  need  more  usable  declarative  properties 
about  the  resulting  machine  code.  As  these  properties  are  not  easily  expressed,  we  identified  the  situations  that 
do  cause  an  error: 

—  covering  problem:  the  root  of  a  rule  tree  does  not  match  the  operator  of  the  referencing  labeled  node,  or  a 
node  firom  a  rule  rooted  somewhere  in  the  labeled  tree  does  not  match  the  operator  of  the  labeled  node  it 
covers  (except  if  the  rule  node  is  a  register  and  covered  node  is  labeled  with  a  rule) 

-  schedule  problem;  there  is  a  node,  labeled  with  a  rule,  having  a  schedule  number  smaller  than  the  one  of  its 
child  node  also  labeled  with  a  rule. 

-  input  problem:  there  is  a  register  node  from  a  rule  rooted  somewhere  in  the  labeled  tree  covering  a  node 
not  labeled  with  a  rule,  or  covering  a  node  with  a  rule  whose  output  register  variable  is  not  assigned  to  the 
same  instance  as  the  covering  register. 

—  overwrite  problem;  there  is  a  node,  labeled  with  a  rule  and  with  a  schedule  number  comprised  between  the 
schedule  numbers  of  two  “communicating”  rules  using  the  value  passing  register  as  output  or  temporary 
node. 

If  none  of  these  situations  is  encountered,  the  values  of  the  sub-expressions  should  be  computed  correctly,  in 
time,  stored  and  retrieved  in  the  proper  registers,  and  the  temporary  storages  should  be  made  in  a  secure 
manner.  This  should  imply  the  correctness  of  the  code  generated.  It  will  have  to  be  established  formally  by 
an  induction  proof  on  the  structure  of  the  initial  expression  with  help  of  the  correctness  property  of  the  rule 
schemata. 

To  express  these  properties  we  need  a  function  that  retrieves  the  rule  node  covering  a  subnode  of  the 
expression  tree.  The  subset  of  nodes  covered  by  a  rule  is  defined  by  the  predicate  rule_covers_subtree?  and 
the  function  cover  ing-op  retrieves  the  operator  from  the  rule  tree  covering  a  given  node. 
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checker  [ 

R 

:TYPE+. 

X  registers 

y»  Operator  type  and  accessors 

Dp 

:TYPE+, 

Z  operators  in  expressions 

RegVar 

:TYPE+, 

*/,  register  variables 

NumVax 

:TYPE+, 

7,  numerical  variables 

val? 

:pred[0p]  , 

7,  value  operator 

val 

: [(Val?)->int3 , 

7.  accessor  for  value 

reg? 

:pred[0p]  , 

7.  register  variable  operator 

reg 

; C(Reg?)->RegVar] , 

7i  accessor  for  register  variables 

nuffl? 

:pred[0p]  , 

%  numerical  veuriable  operator 

num 

:  [(Nuin?)->NumVar]  , 

7.  accessor  for  numerical  variables 

chits 

: [(Num?)->nat] , 

%  size  of  the  numerical  variable 

nrule 

;nat, 

7i  number  of  translation  rules 

%  Labeled  node  type  and  accessors 

Node 

:TYPE+, 

7.  labeled  nodes 

oper 

: [Nod6->Dp] , 

7.  operator 

rnum 

: [Node->upto (nrule) ] , 

Z  rule  number 

areg 

: [Node->[RegVar->R]] , 

Z  assignment  of  register  vars 

anmn 

:  [Node->  [NvunVar->nat]  ]  , 

Z  assignment  of  numerical  vars 

sched 

: [Node->nat] , 

Z  schedule  number 

Rule  type  and  accessors 

Rule 

:TYPE+, 

Z  translation  rules 

rtree 

: [Rule->Tree [Op] ] , 

Z  operators  tree  of  the  rule 

inp 

: [Rule->finite_set [RegVar]] , 

Z  input  register  vars  of  the  rule 

out 

: [Rule->at_most_one [RegVar] ] 

,  Z  output  register  of  the  rule 

tmp 

:  [Rule->finite_Bet  [RegVar]]  , 

7.  temporary  register  variables 

rulemap 

:  [subranged, nrule)->{r:Rule  |  node? (rtree (r))}]  ’/.  rule  list 

]  :  THEORY 

LTree  : 

TYPE  =  Tree [Node] 

Z  labeled  trees 

RTree  : 

TYPE  =  Tree  [Op] 

Z  rule  trees 

Asg  ; 

TYPE  =  [RegVar->R] 

7.  register  assignements 

Fig.  3.  Parameterization  of  the  PVS  theorj' 
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The  PVS  predicate  wrong.input  presented  in  Fig.  5  encodes  the  input  problem  property  for  the  rule  rooted 
at  t.  It  will  be  usable  in  place  of  the  corresponding  checker  function  (Fig.  4)  in  the  proof  thanks  to  the  lemma 
presented  in  Fig.  6.  We  proceeded  in  a  similar  manner  for  the  three  other  checkers. 

The  proofs  were  done  by  structural  induction  on  the  expression  tree.  The  induction  hypothesis  being  im¬ 
plications,  we  had  to  write  the  checker  functions  in  such  a  way  that  it  is  provable  that  the  successful  check  of 
a  tree  implies  the  same  for  its  subtrees  (in  order  to  “trigger”  the  consequence  part  of  the  implication  of  the 
hypothesis).  These  properties  were  themselves  established  by  structural  induction  and  sometimes  needed  other 
inductive  lemmas  (i.e.  nested  induction). 

The  proofs  are  not  trivial  (a  few  weeks  were  invested  into  specification,  correction,  and  proofs)  but  relatively 
short  (1000  interactive  steps  for  the  whole  theory,  including  TCCs).  They  could  be  further  .automated,  using 
eventually  user-defined  strategies,  but  once  established,  thanks  to  the  parameterization  of  the  theory,  it  will  not 
be  necessary  to  re-work  them. 

We  encoded  in  PVS  a  subset  of  rule  schemata  for  the  translation  from  the  MIS  intermediate  language  to 
DEC-Alpha  and  instantiated  the  checker  theory  for  such  verifications.  The  small  example  presented  in  the 
previous  section  was  successfully  processed. 

The  proof  of  the  global  process  will  be  achieved  by  induction  over  the  schedule  number  of  the  successfully 
checked  labeled  tree.  We  will  consider  a  pair  (code,  tree)  constituted  of  an  assembly  code  sequence  and  an 
intermediate  language  expression  tree.  The  assembly  code  is  considered  to  be  evaluated  prior  to  the  expression, 
bringing  the  machine  in  a  state  (values  stored  in  registers  and/or  memory)  in  which  the  expression  will  then  be 
evaluated.  We  start  with  an  empty  code  sequence  and  the  initial  labeled  expression  tree,  and  the  pair  will  be 
updated  at  each  step  to  a  new  pair  (code  -H-code',  tree')  as  follows: 

—  in  the  expression  tree  the  selected  node  is  replaced  by  a  node  labeled  with  its  output  register  (according  to 
the  substitution)  with  two  leaves  as  sons. 

-  the  assembly  code  part  of  the  rule  associated  to  the  selected  node  (with  its  variables  instantiated  accordingly 
to  the  assignments)  is  appended  to  the  existing  code  sequence. 

The  equivalence  between  the  two  pairs  will  be  established  using  the  declarative  properties  that  were  shown  to 
be  implied  by  a  successful  check  along  with  the  correctness  properties  of  the  translation  rules.  Intuitively,  the 
properties  implied  by  covercheck?(t)  will  be  used  to  show  the  correct  use  of  the  rules  and  the  others  the 
proper  storage  and  retrieval  of  the  subterms  values. 

5  Conclusion 

We  described  in  this  paper  our  approach  to  the  problem  of  formally  specifying  a  validation  procedure  of  the 
results  of  a  compiler  back-end.  We  defined  a  generic  operational  PVS  specification  for  such  a  program  and 
proved  declarative  properties  more  usable  for  the  global  correction  proof.  The  genericity  of  the  specification 
should  allow  an  easy  use  of  the  theory  for  various  intermediate  languages  and  target  machines. 

The  specification  can  be  refined  step  by  step  into  a  PVS  function  close  enough  to  the  actual  encoding  of 
the  checker  in  order  to  prove  its  implementation  correct  (it  is  the  approach  taken  in  [2]).  If  the  checker  is  to 
be  implemented  in  a  higher  level  language,  there  must  exist  a  correctly  implemented  compiler  for  it  (this  initial 
compiler  is  part  of  the  Verifix  project  [5]).  ' 
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val check? (newrule?: bool, t:LTree,r:RTree, a :Asg)  :  RECURSIVE  bool  = 

IF  newrule?  THEN 

CASES  r  OF  new  rule 

leaf:  J.,  '/J  -  shouldn’t  be  empty 

node(vr,lr,rr) : 

CASES  t  OF 

leaf:  X,  */,  -  shouldn’t  cover  a  leaf 

node(vt,lt,rt) :  nor  a  register  (continue  verifying) 

-.reg?(vr)  A valcheck?(±,lt.lr,a)  A  valcheck?(X,rt.rr,a) 
ENDCASES 
ENDCASES 

ELSE  y,  old  rule 

CASES  r  OF 

leaf  :  55  -  is  a  leaf 

CASES  t  OF 

leaf  :  T ,  %  —  and  covers  a  leaf  (ok ,  over) 

node(vt,lt,rt)  :  X  or  covers  a  node  (continue  verifying) 

IF  rnuni(vt)  =  0 

THEN  valcheck?  (± ,  It ,  r ,  a)  A  valcheck?  (X ,  rt ,  r ,  a) 

ELSE  valcheck?(T ,t,rtree(rulemap(rnum(vt)))  ,areg(vt)) 

ENDIF 
ENDCASES, 

node(vr,lr,rr)  :  */.  -  is  a  node 

CASES  t  OF 

leaf  :  X,  —  shouldn’t  cover  a  leaf 

node(vt ,lt,rt)  ;  X  —  covers  a  node,  verify  if  a  value  is 
IF  mum(vt)  =0  required,  cind  passed  if  necessary 

THEN  ->Reg?  (vr) 

ELSE  Reg?(vr)  A-iempty?(out(rulemap(rnum(vt)))) 

Aa(Reg(vr))  =  areg(vt) (choose(out(rulemap(rnum(vt))))) 
Avalcheck?(T ,t,rtree(rulemap(mum(vt)))  ,areg(vt)) 

ENDIF  X  ...  and  continue  verifying 

A  valcheck?  (X ,  It ,  Ir ,  a)  A  val  check?  (X ,  rt ,  rr ,  a) 

ENDCASES 
ENDCASES 
ENDIF 

|mEASURE  lex2(depth(t)  ,  bool2nat(— inewrule?))  either  t  decreases 

y,  or  newrule?  becomes  true 

[valuecheck?(t:LTree)  ;  RECURSIVE  bool  = 

CASES  t  OF 

leaf:  T,  */,  real  verification  starts  at  the  first  node  with  a  rule 
node(v,lt,rt) :  IF  rnum(v)  =  0 

THEN  value check? (It)  A valuecheck?(rt) 

ELSE  valcheck?(T,t,tree(rulemap(rnum(v)))  ,areg(v)) 
ENDIF 

ENDCASES 

jMEASURE  t  by  «  */.  t  is  structurally  decreasing 
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Dold  A.,  Vialard  V.  Formal  Verification  of  a  Compiler  Back-end  Generic  Checker  Program 


369 


y,  t  is  labeled  with  a  rule  that  covers  a  subtree  tl  with  a  register  node 
y,  but  tl  doesn’t  store  a  value  in  the  proper  register 

iwrong_input (t : LTree)  :  bool  = 

CASES  t  OF 
leaf  :  J- , 
node(vt,lt,rt)  : 
rnum(vt)  /=  0 

A3(tl:  (rule_covers_subtree?(rtree(rulemap(rnuin(vt)))  ,t)))  : 
Reg?(covering_op(rtree(rulemap(rnuin(vt)))  ,t)  (tl)) 

A(leaf?(tl) 

Vrnuin(val(tl))  =0 

V  empty? ( out (rulemap (rnum (val (t 1 )))) ) 

V  areg(vt) (Reg(covering_op(rtree (rulemap (mum ( vt) ) ) ,t) (tl))) 

7^  areg (val (t 1 ) ) ( choose (out (rulemap (rnum (val (tl))))))) 

ENDCASES 


Fig.  5.  Declarative  characterization  of  the  input  prpblem 


y.  If  t  is  valuechecked  then  it  does  not  have  a  subtree  with  an  input 

'/,  problem 

valuecheck_correct 

:  LEMMA 

V(t:  LTree)  : 

valuecheck?(t) 

=>  -i(3(tl:  (subtree?(t)))  :  wrong_input(tl)) 

Fig.  6.  Link  between  operational  specification  and  declarative  property 
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Abstract  This  paper  describes  how  program-checking  can  be  used  to  establish  the  correctness  of  a  com¬ 
piler  front-end  which  was  generated  by  unverified  compiler  construction  tools.  The  basic  idea  of  program¬ 
checking  is  to  use  an  unverified  algorithm  whose  results  are  checked  by  a  verified  component  at  run  time. 
The  approach  not  only  simplifies  the  construction  of  a  verified  compiler  front-end  because  checking  the 
result  of  the  analysis  is  much  simpler  to  verify  than  the  verification  of  a  high  sophisticated  compiler  front- 
end.  It  even  allows  to  define  a  notion  of  front-end  correctness.  Furthermore,  we  are  still  able  to  use  existing 
generators  tools  without  major  modifications.  Additionally,  this  work  points  out  the  tasks  which  still  have 
to  be  verified  and  it  discusses  the  flexibility  of  the  approach. 


1  Introduction 

In  order  to  construct  a  verified  compiler  we  have  to  consider  not  only  the  transformation  and  code  generation 
phase  which  can  be  verified  with  respect  to  the  source  and  target  language  semantics  but  also  the  analysis 
of  programs.  Usually,  work  on  constructing  correct  compilers  ignores  this  analysis  phase.  All  semantic  defini¬ 
tions  of  the  source  language  are  based  on  attributed  structure  trees  obtained  after  semantic  analysis,  see  e  g 
[BMW92,Pet95,Die96,BD96]. 

However,  in  order  to  construct  a  correct  compiler,  the  correctness  of  the  analysis  phase  must  not  be  ignored. 
This  paper  bridges  the  gap,  i.  e.  we  show  how  to  construct  a  correct  front-end.  In  fact,  it  is  not  trivial  to  define 
the  correctness  of  the  analysis  phase.  Basically  it  maps  a  character  sequence  to  attributed  syntax  trees.  But 
how  to  define  correctness  of  this  mapping? 

It  is  common  to  define  semantics  of  programming  languages  on  abstract  or  attributed  syntax  trees.  Hence,  in 
order  to  have  a  complete  language  definition,  the  relation  between  the  source  text  and  the  attributed  syntax 
tree  has  to  be  specified.  Usually,  compiler  writers  prefer  to  use  their  own  representation  of  attributed  syntax 
trees  and  base  the  dynamic  semantics  on  them.  For  a  correct  compiler,  it  must  be  proven  that  the  programming 
language  semantics  used  in  the  compiler  preserves  the  programming  language  semantics.  In  this  paper,  we 
assume  that  this  is  already  being  done.  Hence,  we  have  to  ensure  that  the  relation  between  source  text  and 
attributed  syntax  trees  is  implemented  correctly. 

Instead  of  proving  the  correctness  of  the  analysis  phase,  we  check  the  correctness  of  the  results  produced 
during  the  analysis  dynamically.  For  simplicity,  we  assume  that  the  static  semantics  is  specified  by  an  attribute 
grammar,  and  the  relation  tj)  between  source  text  and  attributed  syntax  trees  is  specified  inductively  over  the 
structure  of  the  syntax  trees.  The  basic  idea  of  front-end  checking  is  first  to  check  the  semantic  analysis  where 
it  is  sufficient  to  check  that  for  every  attribution  rule  m.a  /(mi , . . . ,  m*)  in  AG  the  corresponding  attributes 
of  the  attributed  structure  tree  define  an  equality.  Second,  if  the  result  of  the  semantic  analysis  was  accepted 
we  check  scanner  and  parser  by  checking  whether  the  source  text  is  related  by  4>  to  the  abstract  syntax  tree^! 
Our  approach  allows  the  use  of  front-ends  generated  by  unverified  tools  or  front-ends  implemented  by  hand. 
We  do  not  assume  anything  about  the  implementation  language  of  the  front-end.  Especially  we  do  not  assume 

^  In  the  sequel  we  use  symbol  to  denote  'a  character  sequence,  and  token  to  denote  the  internal  representation  of  a 
particular  symbol. 
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that  it  is  implemented  in  a  language  for  which  there  exists  a  verified  compiler.  Of  course,  the  checker  itself  has 
to  be  verified. 

In  our  case  study  we  use  the  cocktail  tool  box  [GE90]  which  generates  C  programs.  Our  implementation  language 
for  the  checker  part  is  Sather-K  [Goo97],  a  type-safe  object-oriented  language  with  generic  classes  (similar  to 
templates  in  C-|--|-).  The  benefit  of  our  approach  is  illustrated  by  the  number  of  lines  of  codes  which  have  to 
be  verified  in  order  to  prove  the  front-end  implementation  correct.  The  generated  front-end  of  our  case  study  is 
implemented  by  22.000  lines  of  C  code  while  the  checker  consists  of  1.300  lines  of  Sather  code. 

The  following  section  introduces  the  idea  of  program  checking  in  general  and  discusses  related  work.  In  Sect.  3 
we  present  an  architecture  for  front-end  checking  and  describe  the  particular  components  of  the  checker  in  more 
detail.  We  examine  the  checking  of  semantic  analysis,  we  describe  the  checker  for  scanner  and  parser,  and  we 
discuss  correctness  properties  of  each  component  of  the  checker.  In  Sect.  4  we  present  an  example  and  draw 
conclusions  in  Sect.  5.  ' 

2  Basics  and  Related  Work 

Consider  a  program  tt  with  input  x  and  output  y.  Let  P{x)  be  a  precondition  of  tt  and  Q{x,y)  a  postcondition. 
A  program  vr  partially  correct,  iff  for  every  x  satisfying  P{x)  either  tt  refuses  .a;  or  vr  computes  an  output  y  such 
that  Q(x,y)  (i.e.  {Pix)}  y  :=  Tr(x)  {Q(x,y)}  in  Hoare- Triple  notation).  The  idea  of  program  checking  can  be 
summarized  by  the  following  function  tt': 

fun  7r'(x  :T)  :T'  is 
y  :=  Tr{x); 

if  check. 7:{x,  y)  then  return  y,  > 

else  abort 

end 

The  boolean  function  check  jk  must  imply  the  postcondition  Q.  The  following  theorem  shows  the  validity  of  the 
approach. 

Theorem  1  (Program  Checking).  Let'K{x  :T):T'  be  an  unverified  program  without  side-effects,  check.ivix  : 
T,y  :  T')  :  bool  he  a  side- effect  free  function  satisfying  {P(a:)}  z  :=  check -Tr(x,y)  {z  =  true  Q{x,y)}.  Then, 
it  holds  {P{x)}  y  :=  ir'ix)  {Q(x,y)} 

Proof.  We  sketch  the  proof.  It  can  be  formal  using  standard  Hoare  calculus.  Since  tt  is  side-effect  free,  the  input 
X  remains  unchanged.  If  tt'  does  not  abort,  it  returns  y.  The  y  returned  is  the  same  as  the  input  in  check.n{x,y), 
because  check. Tr{x,y)  is  side-effect  free.  Furthermore,  when  y  is  returned  it  must  hold  check. 'K{x,y)  =  true. 
Hence,  it  holds  (3(ic,y). 

Hence,  the  only  assumption  on  tt  is  the  side-effect  freeness.  No  further  assumptions  on  tt  are  made.  The  function 
tt'  therefore  provides  a  bootstrapping  approach  to  construct  partial  correct  programs.  It  is  useful  to  apply  the 
approach  if  the  formal  verification  of  check.ix  is  much  easier  than  that  of  tt  or  the  size  of  tt  is  much  larger  than 
the  size  of  check.ir.  However,  the  difficulty  is  the  assumption  on  the  side-effect  freeness  of  vr.  We  will  call  this 
property  of  a  program  being  side-effect  free  “wrap” -property. 

Our  checker  approach  is  closely  related  to  the  work  of  M.  Blum  on  result-checking  [BK95,WB97]  and  the  ideas 
of  [GG75].  A  more  detailed  discussion  of  the  theoretical  aspects  of  our  approach  can  be  found  in  [GGZ98]. 
Program  checking  is  already  used  in  compiler  construction  for  checking  properties  necessary  to  establish  cor¬ 
rectness  of  a  transformation.  Necula  and  Lee  [NL98]  describe  a  compiler  which  contains  a  certifier  that  auto¬ 
matically  checks  the  type  safety  and  the  memory  safety  of  any  assembler  program  produced  by  the  compiler. 
The  certification  process  detects  statically  compilation  errors  of  a  certain  kind  but  it  does  not  establish  full 
correctness  of  the  compilation.  Nevertheless,  this  work  shows  that  program  checking  can  be  used  to  produce 
efficient  implementations  with  consideration  of  safety  requirements. 

3  The  General  Approach 

For  correctness  purposes  (cf.  Theorem  1)  it  is  crucial  that  the  compiler  can  not  affect  the  behavior  of  the 
checking  components.  Thus  we  have  to  introduce  an  interface  which  guarantees  safe  communication  of  the 
compiler  front-end  and  the  checker.  In  Sect.  3.1  we  discuss  different  implementations  of  the  interface.  Figure 


error 


Pigurel.  A  general  architecture  for  checking  compiler  front-ends 


1  describes  our  architecture  for  compiler  front-end  checking.  The  language  specification  defines  an  attribute 
grammar  AG  which  describes  the  static  semantics  of  the  programming  language  in  question.  The  attribute 
grammar  AG'  used  for  the  generation  of  semantic  analysis  needs  not  to  be  the  same  than  AG.  The  SA  Checker 
verifies  the  validity  of  attribute  values.  If  the  check  does  not  reveal  an  error  then  the  abstract  syntax  tree  is 
passed  to  the  Unparser  which  uses  the  relation  <j>  to  compute  a  sequence  of  symbols.  This  sequence  of  symbols  is 
taken  as  a  reference  the  original  file  is  compared  with.  Of  course  the  comparison  has  to  ignore  white  spaces  and 
comments.  If  the  comparison  succeeds  the  program  was  parsed  correctly.  Otherwise  the  program  is  rejected.  In 
fact,  this  does  not  mean  that  the  program  was  compiled  faulty.  It  just  means  that  the  checker  was  not  able  to 
establish  the  correctness  of  the  compilation.  Of  course  it  is  our  goal  to  build  a  checker  which  is  able  to  check 
the  correctness  of  all  compiled  programs. 

In  Fig.  1  white  boxes  denote  components  which  can  be  used  without  verification  while  grey  boxes  denote  parts 
which  have  to  be  verified  in  order  to  construct  a  correct  front-end.  In  the  following  sections,  we  describe  the 
components  in  more  detail. 

The  checker  implements  the  following  function  where  original  is  a  the  character  representation  of  the  program, 
PSL  IS  Its  AIF  representation,  psather  is  the  corresponding  Sather  representation,  and  reference  is  the  symbol 
stream  produced  by  the  Unparser. 


Check; 

p_Sather  ;=  parse_aif  (p_SL) 
if  correctly_attributed(p_Sather)  then 
reference  ;=  wnparse(p_Sather) 

if  not  compare (reference, original)  then  syntactic  error  end 
else  semantic  error 
end 
end 


parse.aif  h^  to  implement  an  injective  total  function  from  AIF  to  ASTsather  and  is  not  further  discussed  in 
this  paper.  The  functions  correctly.attributed,  unparse,  and  compare  are  described  in  the  next  section. 
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3.1  Safe  Communication  of  Checker  cmd  Front-End 

As  Theorem  1  shows  that  a  compiler  must  be  free  of  side-effects.  This  can  be  ensured  by  strictly  separating 
the  memory  spaces  of  the  compiler  and  its  checker.  If  the  operating  system  is  assumed  to  be  correct^  there  are 
several  alternatives  to  make  sure  that  it  is  impossible  for  the  compiler  to  write  in  the  memory  of  the  checker. 

-  If  the  implementation  language  does  not  allow  pointers  to  the  memory,  we  are  able  to  prove  that  the  compiler 
behaves  safe. 

-  If  checking  and  compiling  are  two  parallel  processes  with  different  memory  spaces  the  operating  system 
assures  that  memory  of  one  process  can  not  be  altered  by  another  process.  Nevertheless,  we  have  to  verify 
and  implement  the  protocol  on  which  the  two  processes  communicate.  In  our  implementation  of  this  protocol, 
compiler  and  checker  communicate  by  mutual  file  access.  The  attributed  structure  tree  is  written  to  a  file 
in  a  general  interchange  format  which  is  then  translated  to  an  internal  representation.  This  representation 
of  the  AST  is  reliable  when  the  check  has  succeeded.  The  interchange  format  is  defined  in  [HG98]. 

3.2  Checking  Semantic  Analysis 

The  general  idea  of  checking  semantic  analysis  is  to  interpret  the  attribute  definition  rules  R  of  the  language 
specification  AG  as  equations  on  the  corresponding  attributes.  Instantiating  these  equations  with  the  attribute 
values  computed  by  the  compiler  (using  AG')  leads  to  a  set  of  equations.  Semantic  analysis  worked  correctly  if 
all  these  equations  together  with  the  conditions  C  on  attribute  values  are  fulfilled. 

The  definition  of  static  programming  language  semantic  is  specified  by  an  attribute  grammar  AG  which  is  based 
on  a  context  free  grammar  G  =  {N,T,  P,  Z)  describing  the  AST.  It  associates  a  set  A{X)  of  attributes  with  each 
symbol  X,  in  the  vocabulary  of  G.  We  write  X.a  to  indicate  that  the  attribute  a  is  an  element  of  A{X).  Each 
node  in  the  structure  tree  of  a  sentence  in  L{G)  is  associated  with  a  particular  set  of  values  for  the  attributes 
of  some  symbol  X.  These  values  are  established  by  attribution  rules  R{p)  —  {Xi.a  4-  f{Xj.b,...  ,Xk.c)}  for 
the  production  p  :  Xq  Xi ..  .X^  used  to  construct  the  tree.  Each  rule  defines  an  attribute  Xi.a  in  terms 
of  attributes  Xj.b,...,Xk.c  of  symbols  within  the  same  production.  In  addition  to  the  attribution  rules,  a 
condition  C(Xi.a, ..  .,Xj.b)  involving  attributes  of  symbols  occurring  in  p  may  be  given.  The  computation  of 
the  attributes  may  require  a  complicated  computation  order.  For  the  checking  we  only  consider  the  rules  and 
conditions  as  equations  Xi.a  =  f{Xj.b, . . .  ,Xfc.c),  where  we  insert  the  values  of  the  attributes.  For  a  particular 
AST  this  leads  to  a  set  of  equations  East- 

Definition  1  (Correctness  of  Semantic  Analysis).  Let  East  be  for  a  particular  AST  the  set  of  equations 
implied  by  the  attribute  grammar  AG.  It  holds: 

correctly -attributed{AST)  ^  Ve  €  East  •  true{e) 

The  checker  implements  a  tree  traversal  and  a  function  equality  which  instantiates  the  equations  and  checks 
their  validity. 

The  checking  of  the  attribution  is  much  simpler  than  computing  the  attributes  according  to  a  special  evaluation  order. 
Thus,  the  attribute  grammar  AG  defined  by  the  language  designer  may  be  different  from  the  attribute  grammar  AG' 
used  for  constructing  the  semantic  analysis.  While  AG'  has  to  have  properties  useful  for  generation,  e.  g.  AG'  has  to  be 
ordered,  AG  needs  only  to  be  well-defined. 

3.3  Checking  the  Correctness  of  Scanner  and  Parser 

Semantic  analysis  together  with  scanning  and  parsing  implements  a  function  from  character  sequences  to  at¬ 
tributed  structure  trees.  It  yields  a  unique  AST  for  a  particular  program.  After  the  checking  of  the  attributed 
structure  tree  it  is  safe  that  the  computed  attributes  are  consistent  with  the  language  specification. 

We  ignore  the  attributes  of  the  AAST.  The  Unparser  implements  the  relation  (j)  defined  by  the  language  designer. 
It  produces  a  sequence  of  symbols,  i.  e.  a  sequence  of  character  sequences  representing  the  relevant  units  of  a 
program.  The  symbols  of  the  reference  sequence  have  to  occur  in  the  same  order  in  the  original  program.  But, 
in  the  original  program,  there  may  exist  additional  white  spaces  and  comments  which  can  be  ignored  because 
they  do  not  carry  semantical  information. 

^  Compiler  verification  does  not  deal  with  hardware  verification  or  verification  of  the  operating  system.  Though  correct¬ 
ness  of  the  base  system  is  essential  for  the  correctness  of  the  global  system  this  is  beyond  the  scope  of  our  work. 
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The  Comparator  processes  the  sequence  of  symbols  produced  by  the  Unparser  and  compares  it  with  the  original 
file.  Informally  spoken  the  comparator  shifts  a  kind  of  window  over  the  character  sequence.  The  information 
about  the  context  of  this  window  is  used  to  determine  the  actions  of  the  Comparator',  ignore  white  spaces,  add 
white  spaces,  over  read  comments,  report  an  error  etc. 

Some  properties  of  existing  programming  languages  require  additional  checking  capabilities: 

-  Valid  symbols  which  are  prefix  of  other  valid  symbols  require  consideration  of  significant  white  spaces  in 
order  to  check  the  principle  of  the  longest  match. 

-  Priorities  of  operators  are  usually  defined  informally  and  are  not  represented  in  the  abstract  syntax.  Thus 
they  have  to  be  checked  separately. 

-  Different  notations  of  the  same  numbers  have  to  deal  with  in  any  case  since  the  actual  values  of  constants 
are  processed  during  compilation®. 

-  Superfluous  symbols,  e.  g.E  or  the  number  of  parentheses,  can  be  ignored  during  the  comparison. 

Checking  the  principle  of  the  longest  match  and  the  priorities  of  operators  is  mandatory  for  correctness.  Treat¬ 
ment  of  superfluous  semantical  information  is  not  crucial  for  the  correctness  of  the  checker  but  improves  its 
quality.  If  superfluous  symbols  occur  in  the  character  sequence  but  not  in  the  AST  it  is  impossible  to  decide 
whether  the  scanner  and  the  parser  were  correct  or  not.  This  does  not  affect  the  correctness  statement.  It  just 
says  that  the  checker  does  not  accept  valid  ASTs. 

Nevertheless,  the  quality  of  the  checker  can  be  improved  by  just  adding  information  to  the  AST.  We  could 
use  information  about  the  derivation  tree  of  the  syntactic  analysis  to  improve  the  comparison.  For  example  we 
could  save  the  number  of  reductions  performed  to  accept  a  parenthesized  expression  in  an  attribute.  During  the 
unparsing  we  create  brackets  according  to  the  number  saved  in  the  tree. 

With  this  simple  strategy  we  are  able  to  define  correct  checkers  for  many  of  the  existing  programming  languages. 
Though  the  checkers  are  not  complete,  we  can  improve  them  using  more  sophisticated  comparison  strategies.  The 
trick  of  generating  a  programming  language  instead  of  parsing  it  eliminates  a  lot  of  problems,  e.  g.  ambiguities 
of  the  grammar  or  special  properties  of  the  acception  mechanism  (LL  or  LR),  which  make  scanning  and  parsing 
quite  complicated. 

Definition  2  (Correctness  of  Unparsing).  The  unparser  is  correct  iff 

ytype  e  NODETYPE  :  Unparse(type)  —  <p{type) 

(f)  is  defined  by  the  language  specifier  and  is  correct  by  definition. 

The  Comparator  is  allowed  to  ignore  characters  which  do  not  carry  information.  Which  characters  carry  infor- 
mation  depends  on  the  actual  programming  language.  Even  white  spaces  may  carry  information  in  some  special 
cases.  This  has  to  be  considered  to  establish  correctness.  In  general,  one  has  to  prove  that  the  comparator 
accepts  the  same  AST  with  or  without  this  additional  Information. 

Compare: 
correct  ;=  true 

while  correct  and  not  (reference. emtpy  and  original . eof)  loop 
if  reference. emtpy  or  original. eof  then 
correct  :=  false 
else 

correct  ;=  match  (head(reference) ,  original) 
reference  :=  tail (ref erence) 
end  —  if 
end  —  loop 


Compare  uses  an  auxiliary  function  match  which  implements  a  finite  automata.  The  properties  of  this  automata 
are  determined  by  the  language  report.  For  our  source  language  match  ignores  superfluous  white  spaces  and 
comments  and  it  maps  different  representations  of  the  same  number. 

®  In  order  to  preserve  simplicity  of  our  checker  we  decided  to  check  correctness  of  the  transformation  of  numbers 
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4  Example 

Our  example  language  defines  simple  expressions  with  variables,  constants,  addition,  and  multiplication.  The 
attribute  grammar  AG  in  Fig.  2  describes  the  abstract  syntax  of  a  simple  language  for  expressions.  The  attribu¬ 
tion  computes  the  “expression  is  constant”  attribute  {b  =  1  ox  b  =  0).  Multiplication  has  higher  precedence  than 
addition.  Addition  is  left-associative.  The  mapping  0  specifies  the  concrete  syntax  for  the  example  language. 
Usually,  0  defines  a  relation  because,  for  convenience,  the  language  designer  allows  ambiguous  representations  for 
the  same  semantics.  The  left-hand  side  of  figure  3  shows  the  AST  representation  of  the  expression  a  *  (3 +4)  H-  6, 


E  Ident  {6  0,id  ;=  STRING} 

I  JntConst  {6  :=  1,  value  :=  INT} 
I  +(Ei,  E2)  {b  :=  bi  Ab2} 

I  *(£'i,£72)  {5  :=  61  A62} 


0(Far)  =  Var.id 
<j){Value)  —  Val.value 
<f>{+{Ei,  E2)  =  <f>{Ei)  '  -H'  4>{E2) 
<j){*{EuE2)  =  <P{Ei)  '  4>{E2) 


Figiire2.  Attribute  grammar  and  mapping  0  from  abstract  to  concrete  syntax 


the  right-hand  side  shows  the  set  of  equations  derived  from  the  attribution  of  the  AST.  The  superscript  of  an 
AST  node  describes  the  attribute  values  computed  by  the  semantic  analysis.  The  subscript  is  a  unique  num¬ 
ber  which  relates  the  AST  node  with  an  equation  on  the  right.  The  function  correctly -attributed  instantiates 
the  equations  corresponding  to  attribution  rules  of  the  abstract  syntax  with  the  attributes  computed  by  the 
semantic  analysis  and  then  checks  the  consistency  of  the  formulae.  The  equations  in  our  example  are  consis¬ 
tent,  cf.  3.  Thus,  semantic  analysis  worked  correctly  and  the  function  unparse,  derived  from  0,  is  invoked.  It 


0,a 

^Ident 
1.3 


/\ 


O.b 

Ident, 

6 


IntConst 


IntConst . 


1.4 


0: 

1: 


2: 


3: 

4: 

5: 

6: 


0  =  0  A  0  --  l.b  A  6.b 
0  =  0  A  1  — •  2.b  A  3.b 
0  =  0  —  Ident.b 

1  =  1  A  1  —  4.b  A  5.b 
1=1  —  IntConst. b 

1=1  —  IntConst. b 

0=0  —  Ident.b 


Figures.  AIF  representation  and  attribute  equations  for  a  +  (3  -f  4)  4-  6 


traverses  the  AST  and  produces  the  stream  ”a”,  ”3”,  ’’-f-”,  ”4”,  ”)”,  ”b”.  Since  unparse  considers 

operator  precedences  the  parentheses  were  inserted.  Thus,  the  original  expression  is  produced  which  establishes 
the  correctness  of  syntactic  analysis. 

We  show  how  the  checker  reacts  on  erroneous  parsers.  Suppose,  the  parser  had  accidently  ignored  the  parantheses 
(or  the  lexer  removed  accidently  the  tokens),  i.e  the  syntax  tree  in  Fig.  4(a)  would  be  produced  by  the  erroneous 
parser.  The  unparser  produces  the  stream  ”a”,  ”3”,  ”-f”,  ”4”,  ”+”,  ”b”.  In  contrast  to  the  above  example, 

parantheses  are  not  included  because  of  the  priorities.  The  comparator  recognizes  that  this  stream  differs  from 
the  input  text. 

Assume  now,  the  parser  accidently  exchanged  priorities  of  and  Then,  it  produces  the  syntax  tree  in 
Fig.  4(b).  The  unparser  produces  the  stream  ”a”,  ”(”,  ”3”,  ”4”,  ”4-”,  ”b”,  ”)”  which  also  differs  from 

the  source  text. 


5  Conclusions 

We  addressed  the  problem  of  compiler  verification  for  real-world  compilers  and  languages  with  the  focus  oh 
the  analysis  phase,  and  presented  a  concrete  front-end  verification  framework.  Our  approach  emphasizes  the 
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Figured.  Erroneous  Syntax  Trees 


C/Sather-K 

Lines  Byte 

Binary  Prog. 

Byte 

Generators  COCKTAIL 

110.000  2.4  MB 

1.2  MB 

Generated  C  Code 

Impl.  IS-Prontend 

22.000  600  KB 

300  KB 

Checker  (Sather-K) 

500  (Parser)  14  KB 

-t-100  (Compare)  3  KB 

-(-700  (AST)  30  KB 

200  KB 

Tablel.  Case  study:  Lines  of  program  code  to  verify  for  a  program-checked  front-end 


software  engineering  aspect,  because  it  bridges  the  gap  between  the  verification  of  such  a  complex  software 
system  and  its  practical  implementation,  especially  with  generators. 

The  proposed  compiler  construction  framework  allows  to  implement  verified  front-ends  down  to  correct  machine 
implementation.  The  main  idea  is  to  assure  correctness  of  the  implementation  by  introducing  runtime  program- 
checkers  that  check  the  result  of  syntactic  and  semantic  analysis.  The  result  of  such  a  ‘checked’  analysis-phase 
is  an  attributed  abstract  syntax  tree,  that  carries  all  the  information  needed  for  the  transformation  phase.  We 
want  to  stress  here  again,  that  this  checking  is  independent  of  the  interleaving  of  semantic  and  syntactic  analysis. 
Even  if  the  syntactical  structure  is  determined  only  after  the  semantic  analysis,  the  checking  can  be  performed 
independently.  Measurements  in  our  case-study  (see  table  1)  show  the  practicability  of  our  approach.  The 
number  of  lines  to  verify  is  decreased  by  a  factor  of  80  compared  to  the  generator  source  and  1:17  compared  to 
generated  C  code.  In  our  case-study  we  compile  a  C-subset  language  IS  [DGG+95,HH98]  to  DEC-alpha  machine 
code. 

Though  we  did  not  discuss  the  correctness  of  the  transformation  and  code  generation  phase,  this  is  part  of  our 
work  in  the  Verifix  project.  VeriSx  is  a  large  scale  case  study  in  program  verification  with  the  major  goal  to 
verify  not  only  specification  and  high  level  implementation  of  compilers,  but  also  to  guarantee  the  correctness  of 
their  final  binary  executables  on  hardware,  cf.  [GDG+96].  State  of  the  art  compiler  construction  uses  complex 
and  high  sophisticated  algorithms  in  order  to  achieve  efficient  code.  Assuring  correctness  by  checking  their 
results  enables  us  to  use  these  algorithms  in  our  verified  compiler  implementation  and  even  to  generate  them 
with  available  unverified  compiler  generators  [DGVZ98]. 

Acknowledgements  This  work  is  supported  by  the  Deutsche  Forschungsgemeinschaft  project  Go  323/3-1 
Verifix  (Construction  of  Correct  Compilers).  We  are  grateful  to  our  colleagues  in  Verifix. 
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Abstract.  Integration  of  non  formal  methods,  notations  and  tools  with  formal  ones  is  a  promising  way  of 
linking  scientific  results  to  the  daily  work  of  practitioners.  In  this  paper,  we  present  a  formal  notation  based 
in  a  synchronous  reactive  execution  semantics  (Synchronous  Reactive  System)  for  graphical  specifications 
(SA/RT  models).  We  use  the  Synchronous  Reactive  System  as  intermediate  format  to  formally  verify 
graphical  specifications  using  the  SMV  model  checker.  We  deal  with  the  state  space  explosion  problem 
using  modular  verification. 


1  Introduction 

Structured  Methods  [18],  also  known  as  Structured  Analysis  for  Real-Time  (SA/RT)  are  a  widespread  graphical 
formalism  that  is  adequate  to  model  Reactive  System  and  it  is  supported  by  a  high  number  of  commercial 
CASE  tools.  But  most  of  them  lack  analytical  capabilities  (usually  limited  to  syntax  checks  such  as  balancing 
or  simulation). 

The  original  (informal)  definition  of  the  semantics  as  proposed  by  Ward  and  Mellor  is  inspired  in  the 
execution  rules  of  Petri  nets.  In  this  paper,  we  shall  use  a  more  up-to-date,  deterministic  and  causal  semantics 
similar  to  the  one  implemented  in  STATEMATE  [9]  or  RSML  [11].  The  essential  difference  with  regard  to 
Ward  s  approach  is  that  more  than  one  transition  can  be  executed  in  parallel  at  each  step. 

Little  work  has  been  made  in  the  model  checking  of  this  type  of  graphical  specifications.  In  a  previous  work 
[17]  we  have  used  SA/RT  methods  in  conjunction  with  SMV  [14],  in  which  the  model  is  executed  as  a  set  of 
interleaved  processes.  In  [6]  and  [7]  Statecharts  are  used,  but  the  semantics  is  not  based  on  the  concept  of  micro 
and  macro -steps  and  not  use  modular  verification.  Anderson  et  al.  [2]  have  used  SMV  to  verify  requirements 
written  in  RSML.  They  perform  a  manual  translation  and  verify  some  interesting  properties  (safety,  transition 
and  function  consistency). 

Most  of  the  current  approaches  to  verification  of  synchronous  systems  (see  e.g.  [10])  perform  a  first  step 
in  which  a  global  transition  graph  is  elaborated  and  verification  is  performed  on  this  global  graph  (the  same 
as  the  one  that  is  produced  by  the  compilation  process  in  Esterel  programs  [4]).  But  the  verification  using  a 
precompiled  transition  graph  does  not  resolve  the  state  explosion  problem,  because  if  the  system  is  composed 
of  different  subsystems  that  are  not  tightly  coupled,  the  total  number  of  states  increases  exponentially.  In  such 
cases,  it  is  very  important  to  partition  the  model  and  to  perform  separate  verifications  on  each  part  of  the  model 
(modular  verification). 

In  the  Section  2  we  describe  the  computational  model  of  Synchronous  Reactive  Systems  which  we  use 
as  intermediate  format  to  compile  the  graphical  specification.  In  the  Section  3  we  sketch  the  procedure  of 
translation  from  Synchronous  Reactive  System  into  the  language  accepted  by  a  model  checker  (SMV  [14]),  and 
show  how  we  can  perform  the  modular  verification.  Finally,  in  Section  4  some  conclusions  and  future  work  are 
presented. 


2  The  Framework  of  Synchronous  Reactive  Systems 

In  this  section,  we  present  a  brief  introduction  to  the  SA/RT  models  and  we  show  the  underlying  computational 
model  that  we  denoted  Synchronous  Reactive  System  (SRS). 

This  work  has  been,  funded  by  the  ”Comisi6n  Interministerial  de  Ciencia  y  Tecnologia”  (Spain)  under  project  EDIC 
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2.1  SA/RT  methods 

SA/RT  is  a  short  name  for  Structured  Analysis  methods  with  extensions  for  Real  Time.  Using  Structured 
Methods  we  can  view  the  model  of  the  system  as  a  leveled  set  of  diagrams  that  include  concurrent  processes 
and  the  communication  between  them.  Each  process  communicates  with  others  and  with  the  environment  using 
data  and  control  flows  (in  our  model  only  control  flows  are  needed  and  we  shall  denote  them  events).  Each 
process  is  decomposed  into  a  diagram  showing  a  more  detailed  view.  The  primitive  control  processes  (processes 
which  not  decompose  in  other)  are  specified  using  State  Transition  Diagrams  (STDs). 

2.2  State  Transitions  Diagrams 

In  the  SA/RT  methods  [18],  the  behaviour  of  a  primitive  control  process  is  defined  using  a  State  Transition 
Diagram  or  STD.  An  STD  contains  all  states  that  the  process  may  reaches  and  all  transitions  that  it  may 
performs.  In  the  rest  of  this  paper,  we  use  the  term  ’’process”  and  ”STD”  indistinctly,  due  to  there  is  a  mapping 
between  a  process  and  its  STD, 

Definition  1.  An  STD  is  a  5-tuple  <  17,  0,  ^  >  where 

—  S  is  the  set  of  states. 

—  So  is  the  initial  state  of  STD,  So^S 

—  I  is  the  set  of  input  events  that  the  STD  receives 

—  O  is  the  set  of  output  events  that  the  STD  produces,  I  DO  =  <Z) 

—  S  is  the  transition  relation,  S  C  (17, 1, 0, 17) 

Usually,  we  denote  the  transition  r  =  (s,c,a,s')  E  6  using  the  notation  s  — s',  which  means  that  STD 
executes  the  transition  r  when  it  receives  the  input  event  c  (see  Remark  1),  changing  to  state  s'  and  producing 
the  set  of  output  events  a  C  O.  In  the  context  of  individual  transitions,  we  shall  refer  to  the  pair  (c,  a)  like  label 
of  transition  and  we  shall  refer  to  c  like  condition  and  a  like  action.  All  STD  implicitly  has  a  control  variable  or 
control  state  tt,  which  denotes  the  local  state  of  process  (initially  n  —  sq).  A  transition  r  =  (s,  c,a,s')  is  enabled 
if  (tt  =  s)  and  the  evaluation  of  c  is  true.  The  set  of  enabled  transitions  in  a  state  s  is  denoted  as  enabled{s). 

Remark  1.  The  original  syntax  from  V/ard  [18]  specifies  that  a  condition  in  an  STD  must  be  composed  only 
of  control  flows  (individual  events).  In  order  to  achieve  a  higher  expressiveness  of  the  specification,  we  allow 
the  conditions  to  be  formed  by  logical  expressions  of  events  of  I,  values  of  the  states  of  other  processes  and  the 
proposition  true  (equivalent  to  the  ’’blank”  condition  in  the  graphical  model). 

2.3  Synchronous  Reactive  Systems 

An  SRS  consists  of  a  set  of  STDs  interacting  over  a  set  of  input  events  and  a  set  of  output  events.  The  events 
that  communicate  STDs  we  denote  them  internal  events  due  to  this  events  are  not  observable  out  of  the  SRS. 

The  semantics  adopted  to  describe  the  behaviour  of  SRS  is  related  with  the  concepts  of  Berry’s  synchronous 
hypothesis  [4]  (the  system  reacts  instantaneously  to  external  events)  and  the  semantics  of  Micro/Macro  Step 
in  STATEMA'TE  [9]  and  RSML  [11].  Basically,  we  can  view  the  execution  of  the  SRS  as  infinite  series  of 
macro  —  steps  that  produce  sequences  of  output  events  in  response  to  input  events,  and  internally,  the  execution 
can  be  viewed  as  a  chain  of  micro  —  steps.  At  each  one,  the  system  will  reacts  to  the  input  events  producing 
output  events  and  internal  events  that  initiate  other  micro  —  step  until  no  more  micro  —  step  can  be  taken. 

Definition  2.  A  Synchronous  Reactive  System  (SRS)  $  is  a  5-tuple 
jA,GE, IE,C)E, — where 

—  A  =  {Ml,  M2, . . . ,  Mn)  is  the  set  of  STDs  that  compound  ^ 

—  GE  is  the  set  of  internal  events  that  communicate  the  STDs  in  A, 

G£7  =  (U/i)n([JOi) 

j=l  i=l 

—  IE  is  the  set  of  input  events  that  receives  of  the  environment, 

n 

IE  =  [jli-GE 
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OE  is  the  set  of  output  events  that  $  produces  to  the  environment, 

n 

OE=\JOi-GE 


t=l 


IS  the  transition  relation  of  $  which  describes  the  semantics  outline  above  and  we  shall  define  in  the 

oGQUCl, 


The  initial  state  of  ^  is  formed  by  the  set  of  the  initial  states  of  the  STDs  in  zi,  5o  =  {so,  si ,  •  •  • ,  Sn)  An 
state  (global  state)  5  of  #  is  composed  by  the  control  states  of  the  STDs  in  z\,  S  =  (tti  , . . . ,  We’  dLoted 
^  ^  /T  configuration  of  The  set  of  all  possible  configurations  of  $  is  denoted  by 

Global.  We  shall  describe  the  transition  relation  — Global{^)  x  Globaim  in  basis  to  the  following 
inference  rules  (similar  to  [12]): 

R-ulesrApplies  to  an  STD  Mi  if  it  has  an  enabled  transition  in  a  state  of  the  current  configuration. 
If  the  STD  have  multiples  enabled  transitions  in  the  configuration,  one  of  them  is  taken  non-deterministically: 


_ (TTj  =  Sj)  A  {3Ti  :  Sj  — >l\  s\  £  SilTj  6  enabled[si))  _ 

((tti , . . . ,  Sj, . . . ,  7r„), IE, OE,GE)  — ((vri ,  •  •  • ,  s[, . . . ,  Tin),  0,  OE  U  Oj,  0) 

If  various  STDs  of  SRS  have  enabled  transitions,  then  each  of  them  execute  simultaneously: 


(1) 


(TTj  =  Sj)  A  (3Tj  :  Sj  — s'i  G  di/n  €  enabled{si)) 

(tTj  =  Sj)  a  (3rj  :  Sj  — s'-  6  djfrj  €  enabled{sj)) 

((tti , . . . ,  Sj, . . . ,  Sj,  . . . ,  7r„),  IE,  OE,  GE) 

((iTi , . . . ,  s^ , . . . ,  Sj- , . , . ,  7r^) ,  0, 0£' U  Oj  U  ,  0) 

Stuttering  Rule:  If  an  STD  Mj  is  in  a  state  in  the  current  configuration  and  it  does  not  have  any  enabled 
transition,  then  it  consumes  events  but  it  does  not  produce  events.  This  notation  is  adequate  to  represent  the 
concept  of  reactivity(in  any  state,  there  exist  at  least  one  transition  to  execute): 


(TTj  =  Sj)  A  (3rj  :  Sj  — s[  £  Sj/n  ^  enabled{si)) 


((tti , . . . ,  Sj, . . . ,  TTn),IE,  OE,  GE)  — ((tti , . . . ,  Sj, . . . ,  7r„),  0,  OE,  0) 


(3) 


The  above  rules  show  the  execution  of  the  SRS  at  level  of  micro  -  step.  When  all  STDs  Mi  M  in 
the  SRS  only  can  to  advance  executing  the  rule  3,  the  SRS  has  reached  to  an  stable  configuration  (no  more 
transitions  can  be  taken). 

At  level  of  macro  -  step,  the  execution  of  SRS  can  be  viewed  like  a  sequence  of  stable  configurations,  where 
at  each  one,  the  SRS  receives  input  events  IE  and  produces  output  events  OE: 

C  =  {S,IE,Q),(Z>) =  {S',Q),OE,(d)  (4) 

where  S  and  5'  represent  the  global  states  of  SRS  before  and  after  of  the  macro  -  step,  C'  is  an  stable 
configuration  and  — represents  a  chain  of  micro  -  steps: 


3  Verification  of  SRS 


The  mtermedia-te  format  presented  in  the  later  section  is  translated  into  the  language  accepted  by  the  SMV 
[14]  model  checlmr.  In  the  SMV  language,  we  can  specify  the  operational  model  and  check  its  desired  properties 
written  m  CH.  Temporal  Logic  [5].  The  execution  of  an  SMV  specification  can  be  viewed  as  a  sequence  of  steps 
that  change  the  values  of  variables  according  to  the  transition  relation  of  the  automata  represented  by  the  SMV 
code.  We  shall  outline  the  translation  procedure  of  the  semantics  ( — and  — ^#^)  to  SMV  and  how  we  include 
support  for  performing  modular  verifications. 
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3.1  Translating  SRS  into  SMV 

The  execution  of  each  macro  -  step  consists  of  a  first  step,  in  which  the  changes  produced  in  the  environment 
are  perceived,  and  a  sequence  of  micro  —  steps,  until  a  stable  configuration  is  reached.  Since  SMV  executes 
step  by  step,  without  any  difference  between  steps,  we  must  differentiate  the  first  step  from  the  others  using  a 
special  variable  named  MicroStep.  The  following  pseudo-code  reproduces  the  behavior  of  — 

if  MicroStep  =  0  then 

Allow  changes  in  external  inputs  and  set  MicroStep  =  1 
else 

if  some  transition  can  be  executed  then 
Perform  a  micro-step  by  executing  transitions 

else 

Set  MicroStep  =  0 

end  if 
end  if 

We  use  a  boolean  variable  for  each  event  and  a  variable  for  representing  the  state  of  process  (namely,  w). 
Changes  of  each  variable  representing  an  external  input  event  ini  €  IE  are  performed  by  sentences  that  set  the 
event  to  a  random  value  only  when  the  value  of  MicroStep  is  0.  Otherwise  its  value  will  be  set  to  0  (external 
input  events  can  influence  only  the  first  micro  —  step) : 

next (ini)  :=  case 
MicroStep=0  : 

1:0; 

esac; 

The  execution  of  each  micro  -  step  (— >'*)  follows  a  similar  schema,  but,  since  we  need  to  know  if  some 
transitions  where  enabled  or  not  in  order  to  decide  whether  to  continue  the  chain  of  micro  -  steps  or'  not,  we 
use  an  additional  variable  TP  for  each  process,  that  represents  the  transition  that  will  be  executed.  For  instance, 
if  two  transitions  n  and  T2  leave  the  state  SO  towards  SI  and  S2,  having  conditions  Cl  and  C2  respectively,  we 
first  select  the  transition  to  be  executed  with  a  direct  assignment  (if  no  transition  can  be  executed,  then  TP  is 
set  to  0); 

TP  ;=  case 

MicroStep=l  &  pi=S0  &  Cl  :  1; 

MicroStep=l  &  pi=S0  &  C2  :  2; 

1:0; 

esac; 

The  SMV  case  sentence  is  deterministic:  it  selects  the  first  row  that  has  the  condition  true.  If  we  want  the 
selection  to  be  non-deterministic,  we  can  do  as  shown  in  [17]. 

Output  events  and  next,  states  are  set  according  to  the  value  of  this  variable.  For  instance,  if  event  cndl  qOE 
is  sent  as  a  consequence  of  the  execution  of  transition  t\  and  also  as  a  consequence  of  another  transition  ra,  the 
next  value  for  outl  will  be: 

next(outl)  ;=  case 
TP=1  I  TP=3  :  1; 

1  :  0; 
esac; 

The  last  term  sets  the  value  to  zero  for  the  same  reason  as  in  external  input  events. 

The  next  state  (assuming  that  variable  pi  holds  its  value)  will  be  coded  as: 

next (pi)  :=  case 
TP  =  1  :  SI; 

TP  =  2  :  S2; 

1  :  pi; 
esac; 
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The  chain  of  micro  steps  finishes  when  no  transition  can  be  executed.  For  instance,  if  we  have  two  processes 
in  the  SRS,  each  one  having  its  own  variable  (TPl  and  TP2)  which  indicates  the  transition  executed,  we  shall 
have: 

next (MicroStep)  :=  case 
MicroStep=0  :  1;  —  environment  has  changed 

TP1=0  k  TP2=0  :  0;  —  end  of  macro-step 

1  ;  MicroStep; 
esac; 

3.2  Approach  for  Modular  Verification 

Due  to  the  state  explosion  problem,  when  the  size  of  the  system  grows,  it  is  desirable  to  be  able  to  perform  local 
verifications  in  separate  components  and  deduce  some  global  property  for  the  whole  model.  This  procedure  can 
be  called  Modular  Verification  and  is  based  on  the  Abadi  and  Lamport  composition  theorem  [1],  also  known  as 
rely-guarantee  or  assumption-commitment  rules.  If  a  model  #  can  be  decomposed  into  the  parallel  composition 
of  two  (or  more)  components  (SRSs)  [#i||^2],  we  can  perform  the  verification  of  local  properties  (^i,  02 )  for 
each  component  (^i  or  ^2,  respectively)  assuming  some  kind  of  behavior  for  the  other  (abstracted)  component. 
For  instance,  we  can  prove  that  02  is  true  for  the  component  #2  assuming  certain  behavior  0B1  of  the  abstracted 
model  #1,  and  symmetrically  for  #1.  If  we  also  prove  that  (j)Ei  is  true  for  #1  (discharge  the  assumption)  and 
its  symmetric  (0^2  is  true  on  #2),  then  property  0i  A  02  will  be  true  for  the  whole  model  #  provided  that 
assumptions  are  safety  properties  [1]. 

When  we  divide  the  model  into  different  SRSs  (each  one  groups  several  processes  in  the  SA/RT  model), 
internal  events  that  communicate  them  must  be  treated  differently  to  the  others.  We  name  these  Ghost  Events 
and  at  each  micro  —  step  we  set  their  values  to  random  ones.  A  safety  property  which  is  true  in  the  component 
will  also  be  true  in  the  whole  model  (the  converse  is  not  true,  since  this  simplification  introduces  additional 
computations  that  may  not  be  present  in  the  whole  model). 

When  including  ghost  events,  the  termination  of  each  macro  -  step  (determined  by  the  portion  of  code  that 
gives  a  value  to  the  variable  MicroStep)  must  be  modified  to  take  into  account  the  fact  that  if  at  some  step  no 
transition  is  enabled,  the  abstracted  model  may  still  be  executing  a  transition  that  will  send  a  ghost  event  at 
the  next  micro  -  step.  The  end  of  the  macro  -  step  must  include  additional  conditions  to  avoid  finishing  when 
the  next  value  of  some  ghost  event  has  been  sent.  For  instance,  assuming  that  we  have  two  variables  (gl  and 
g2)  representing  ghost  events,  the  above  fragment  will  be: 

next (MicroStep)  :=  case 
0:1;  —  environment  has  changed 

next(gl)=0  &  next(g2)=0 

k  TP1=0  k  TP2=0  :  0;  —  end  of  macro-step 

1  :  MicroStep; 
esac; 

When  we  wish  to  specify  some  kind  of  assumption,  we  use  a  set  of  simple  rules  coded  as  sentences  like: 
ASSUME{cond,g,v),  which  states  that  if  condition  cond  is  true,  then  variable  g  must  have  the  value  v. 
Assumptions  are  included  in  the  portion  of  code  that  sets  a  value  to  the  ghost  event  as  shown  below  (recall  that 
the  case  sentence  selects  the  first  condition  that  is  true): 

next(g)  :=  case 

MicroStep=l  &  cond  :  v; 

—  other  assumptions  ... 

MicroStep=l  :  -{0,1};  —  possible  change 

1:0;' 
esac ; 

3.3  Specification  of  properties 

System  properties  must  be  checked  at  the  end  of  each  macro  -  step.  It  suffices  to  transform  a  formula  AGU) 
where  0  is  another  CTL  formula  or  proposition,  into  ’ 

AG(MicroStep  =  0-^0) 
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Due  to  a  high  number  of  properties  of  interest  being  input/output  responses,  which  relate  input  with  output 
events,  and  the  values  of  input  events  are  maintained  only  at  the  first  Micro  -  step,  we  also  provide  a  predicate 
WASOif)  which  is  true  if  /  was  true  at  some  micro  -  step  of  the  current  macro  -  step.  Using  an  additional 
variable  for  each  one,  the  translation  is  straightforward. 

When  we  discharge  an  assumption  (commitment)  in  the  form  ASSUME{cond,g,v),  we  use  a  CTL  formula 
that  is  checked  at  each  micro  —  step  like; 

AG{MicroStep  =  1  ->  (ccmd  g  =  v)) 

An  essential  property  of  this  type  of  model  is  the  absence  of  a  kind  of  livelock  situation  in  which  the  system 
is  executing  an  infinite  chain  of  micro  -  steps  (step  termination).  This  situation  is  checked  with  the  following 
CTL  formula: 

AG{MicroStep  =  1  ->  AF{MicroStep  =  0)) 

When  we  try  to  prove  this  property  in  a  component  that  has  some  ghost  events  as  input,  an  important  risk 
is  that  of  falling  into  false  infinite  loops  caused  by  an  infinite  sequence  of  these  events.  In  that  case,  a  common 
assumption  is  to  prevent  a  ghost  event  from  appearing  more  than  once  (or  more)  in  a  macro  —  step:  it  suffices 
to  use  a  Bssuiaptions  like  AS  SUM  E{WAS0(g),g,0). 

4  Conclusions 

The  approach  taken  for  modular  verification  of  synchronous  reactive  system  allows  mitigate  the  effects  of  the 
state  explosion.  Although  a  compilation  of  the  synchronous  model  previous  to  its  model,  checking  (as  in  [10]) 
is  more  efficient  due  to  the  elimination  of  all  m.icro  —  steps  and  so,  its  corresponding  states),  the  explicit 
representation  of  all  micro  —  steps  allows  us  to  state  the  adequate  assumptions  and  prove  them  without  any 
distortion  of  the  semantics  of  the  whole  model.  The  assumptions  used  are  composed  by  a  number  of  simple 
rules  whose  translation  into  code  is  straightforward.  Nevertheless,  they  must  be  obtained  manually,  which  can 
be  a  difficult  task  if  the  interface  is  complex.  So,  our  present  work  is  addressed  to  attaining  these  constraints  in 
a  more  automatic  way. 

We  think  that  the  use  of  modular  verification  might  be  essential  when  the  model  is  composed  of  relatively 
independent  devices.  The  result  in  [15]  and  [8]  confirm  our  idea  that  it  is  possible  to  (nearly)  interactively 
perform  verifications  of  interesting  properties  of  a  system  as  we  describe  in  [16],  thus  making  model  checking  a 
powerful  tool  for  detecting  bugs  and  for  debugging  the  specification. 
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